Sun JDK vs OpenJDK - Sun JRE vs OpenJDK JRE

[Frans Thamura-2]

anyone have a list that compare Sun JDK with OpenJDK and also OpenJDK
JRE with "Sun JRE

i think we need to know, that the missing tech must be known by public
also for their future investment reason


esp the stock of sun is 6.4 billion, we dont know the future of Java,
but OpenJDK is the future of Java

--
--
Frans Thamura
Meruvian Group
One Stop Java and Enterprise OSS Provider
Technopreneurship, Training, Internship, Outsourcing and Corporate
Competency Center

Mobile: [phone]
Blog & Profile: http://frans.thamura.info

Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan...
URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco

[Dalibor Topic-5]

Frans Thamura wrote:
> anyone have a list that compare Sun JDK with OpenJDK and also OpenJDK
> JRE with "Sun JRE
There is no OpenJDK JRE, specifically. The comparison that makes sense
is one between
Sun Java SE 6 JDK and the OpenJDK jdk6 project.

Differences are:

a) licenses:

OpenJDK jdk6 is Free Software, Sun's Java SE 6 JDK downloads are not, in
particular because
* they contain proprietary third party components (also known as
'encumbrancies'), that wouldn't be trivial to rip and replace in a
stable release series
* they contain Sun's own proprietary code that has not been / could not
be opened up so far

b) deployment code:

OpenJDK does not have a plugin or a webstart implementation.

The code Sun has in the deployment area has been largely rewritten for
Java SE 6 update 10, and the new code,
being a significant chunk of software, requires a new run through the
business decision making process on Sun's side.

Meanwhile, the IcedTea project augments the OpenJDK jdk6 project with
independent implementations
of the plugin and webstart, called gcjwebplugin and netx. Those
independent implementations have a different
set of strengths and weaknesses from Sun's implementations: they work on
64 bit Linux, for example, a platform
that hasn't been supported by Sun's own plugin yet. On the other hand,
gcjwebplugin currently lacks an
adequate Java-JavaScript integration that's required by some applets to
execute as well as expected.

c) bundled code:

Sun's Java SE 6 download comes with a lot of (third party) software
bundled in, for example
Java DB, Rhino, Visual VM, etc. OpenJDK jdk 6 project leaves such
software out as much as possible,
concentrating on the necessities required for a compatible
implementation of Java SE 6.

IcedTea augments OpenJDK jdk6 with Rhino, though there is still work to
be done on making the integration seamless.
There is also some initial work on integrating VisualVM into IcedTea.

d) encumbered code:

The Java SE 6 JDK still mostly contains the ~4 % of encumbered, i.e.
third party code that couldn't be licensed as
Free Software, and  was replaced by open source implementations from the
community in OpenJDK 6.

cheers,
dalibor topic

--
*******************************************************************
Dalibor Topic                   Tel: [phone]
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: [phone]
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic@...
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring

[Geir Magnusson Jr.-3]

On Sep 13, 2008, at 9:44 AM, Dalibor Topic wrote:

> Frans Thamura wrote:
>> anyone have a list that compare Sun JDK with OpenJDK and also OpenJDK
>> JRE with "Sun JRE
> There is no OpenJDK JRE, specifically. The comparison that makes sense
> is one between
> Sun Java SE 6 JDK and the OpenJDK jdk6 project.
>
> Differences are:
>
> a) licenses:
>
> OpenJDK jdk6 is Free Software, Sun's Java SE 6 JDK downloads are  
> not, in
> particular because
> * they contain proprietary third party components (also known as
> 'encumbrancies'), that wouldn't be trivial to rip and replace in a
> stable release series
> * they contain Sun's own proprietary code that has not been / could  
> not
> be opened up so far

Like what?  And why can't it be opened up?

>
>
> b) deployment code:
>
> OpenJDK does not have a plugin or a webstart implementation.
>
> The code Sun has in the deployment area has been largely rewritten for
> Java SE 6 update 10, and the new code,
> being a significant chunk of software, requires a new run through the
> business decision making process on Sun's side.

I thought you already made the decision to "open source" java, and  
beyond that, there's Schwartz's commitment to "open source" everything.

I know this might come across as trolling,  but I am honestly  
mystified why Sun isn't just going all-in here and just put anything  
that is their property out under the GPL (I realize there's encumbered  
stuff, but you should just jettison that stuff and get the  
replacements from the community).  Sun maintains the control they need  
for the business, and the software receives the "freedom" for which  
RMS feels it so richly deserves :)

Seriously though... why not just OSS it?

>
> Meanwhile, the IcedTea project augments the OpenJDK jdk6 project with
> independent implementations
> of the plugin and webstart, called gcjwebplugin and netx. Those
> independent implementations have a different
> set of strengths and weaknesses from Sun's implementations: they  
> work on
> 64 bit Linux, for example, a platform
> that hasn't been supported by Sun's own plugin yet. On the other hand,
> gcjwebplugin currently lacks an
> adequate Java-JavaScript integration that's required by some applets  
> to
> execute as well as expected.

Seems like Sun is using IcedTea as a kind of "shadow project"?  I  
don't follow things closely anymore, but someone was asking me about  
this the other day and I couldn't really explain it clearly.   I find  
the whole thing baffling.  Now that you are a Sun employee and  
historically have been direct and honest, can you tell us about how  
this is structured?

It appears that there are three repos of Sun-sourced Java code :

1) openjdk, which seems to be an incomplete implementation  repository  
meant to feed...

2) IcedTea, which provides build infrastructure and patches the stuff  
sun can't or doesn't want to OSS, which itself seems to have a good  
community

3) Sun's internal repo from which their Java SE product builds are  
created (confusingly referred to as the RI...), and .... from which  
the misnamed "JDK 7" builds are created from?

Is the latter true?  I've never been able to grok where the JDK 7  
stuff comes from.  I'd have thought all work would be done out here in  
the opendjk community (after all, it's been *years* since Sun  
announced the project...) but...

Any insight you can provide as an insider would be welcome.

>
>
> c) bundled code:
>
> Sun's Java SE 6 download comes with a lot of (third party) software
> bundled in, for example
> Java DB, Rhino, Visual VM, etc. OpenJDK jdk 6 project leaves such
> software out as much as possible,
> concentrating on the necessities required for a compatible
> implementation of Java SE 6.

I don't know about VisualVM, but the rest is free/open  software.  Why  
not just include those as well?

>
>
> IcedTea augments OpenJDK jdk6 with Rhino, though there is still work  
> to
> be done on making the integration seamless.
> There is also some initial work on integrating VisualVM into IcedTea.
>
> d) encumbered code:
>
> The Java SE 6 JDK still mostly contains the ~4 % of encumbered, i.e.
> third party code that couldn't be licensed as
> Free Software, and  was replaced by open source implementations from  
> the
> community in OpenJDK 6.

So why not jettison the 3rd party code and focus the community around  
the open/free stuff?  Seems like the thing to do if Java is free.  I  
can understand not doing it right off the bat, but it's been years  
now...

geir

[Frans Thamura-2]

Strange that sun still cannot understand the community model, and keep
several "Third party" but we dont know which one, which library and
why there is not opensource version...

why dont u openup and said, this is not opensourced.


what did you said in J1.. the  JDK is 100% OpenSourced ...


still strange...

On 9/13/08, Geir Magnusson Jr. <geir@...> wrote:

>
> On Sep 13, 2008, at 9:44 AM, Dalibor Topic wrote:
>
>> Frans Thamura wrote:
>>> anyone have a list that compare Sun JDK with OpenJDK and also OpenJDK
>>> JRE with "Sun JRE
>> There is no OpenJDK JRE, specifically. The comparison that makes sense
>> is one between
>> Sun Java SE 6 JDK and the OpenJDK jdk6 project.
>>
>> Differences are:
>>
>> a) licenses:
>>
>> OpenJDK jdk6 is Free Software, Sun's Java SE 6 JDK downloads are
>> not, in
>> particular because
>> * they contain proprietary third party components (also known as
>> 'encumbrancies'), that wouldn't be trivial to rip and replace in a
>> stable release series
>> * they contain Sun's own proprietary code that has not been / could
>> not
>> be opened up so far
>
> Like what?  And why can't it be opened up?
>
>>
>>
>> b) deployment code:
>>
>> OpenJDK does not have a plugin or a webstart implementation.
>>
>> The code Sun has in the deployment area has been largely rewritten for
>> Java SE 6 update 10, and the new code,
>> being a significant chunk of software, requires a new run through the
>> business decision making process on Sun's side.
>
> I thought you already made the decision to "open source" java, and
> beyond that, there's Schwartz's commitment to "open source" everything.
>
> I know this might come across as trolling,  but I am honestly
> mystified why Sun isn't just going all-in here and just put anything
> that is their property out under the GPL (I realize there's encumbered
> stuff, but you should just jettison that stuff and get the
> replacements from the community).  Sun maintains the control they need
> for the business, and the software receives the "freedom" for which
> RMS feels it so richly deserves :)
>
> Seriously though... why not just OSS it?
>
>
>>
>> Meanwhile, the IcedTea project augments the OpenJDK jdk6 project with
>> independent implementations
>> of the plugin and webstart, called gcjwebplugin and netx. Those
>> independent implementations have a different
>> set of strengths and weaknesses from Sun's implementations: they
>> work on
>> 64 bit Linux, for example, a platform
>> that hasn't been supported by Sun's own plugin yet. On the other hand,
>> gcjwebplugin currently lacks an
>> adequate Java-JavaScript integration that's required by some applets
>> to
>> execute as well as expected.
>
> Seems like Sun is using IcedTea as a kind of "shadow project"?  I
> don't follow things closely anymore, but someone was asking me about
> this the other day and I couldn't really explain it clearly.   I find
> the whole thing baffling.  Now that you are a Sun employee and
> historically have been direct and honest, can you tell us about how
> this is structured?
>
> It appears that there are three repos of Sun-sourced Java code :
>
> 1) openjdk, which seems to be an incomplete implementation  repository
> meant to feed...
>
> 2) IcedTea, which provides build infrastructure and patches the stuff
> sun can't or doesn't want to OSS, which itself seems to have a good
> community
>
> 3) Sun's internal repo from which their Java SE product builds are
> created (confusingly referred to as the RI...), and .... from which
> the misnamed "JDK 7" builds are created from?
>
> Is the latter true?  I've never been able to grok where the JDK 7
> stuff comes from.  I'd have thought all work would be done out here in
> the opendjk community (after all, it's been *years* since Sun
> announced the project...) but...
>
> Any insight you can provide as an insider would be welcome.
>
>>
>>
>> c) bundled code:
>>
>> Sun's Java SE 6 download comes with a lot of (third party) software
>> bundled in, for example
>> Java DB, Rhino, Visual VM, etc. OpenJDK jdk 6 project leaves such
>> software out as much as possible,
>> concentrating on the necessities required for a compatible
>> implementation of Java SE 6.
>
> I don't know about VisualVM, but the rest is free/open  software.  Why
> not just include those as well?
>
>>
>>
>> IcedTea augments OpenJDK jdk6 with Rhino, though there is still work
>> to
>> be done on making the integration seamless.
>> There is also some initial work on integrating VisualVM into IcedTea.
>>
>> d) encumbered code:
>>
>> The Java SE 6 JDK still mostly contains the ~4 % of encumbered, i.e.
>> third party code that couldn't be licensed as
>> Free Software, and  was replaced by open source implementations from
>> the
>> community in OpenJDK 6.
>
> So why not jettison the 3rd party code and focus the community around
> the open/free stuff?  Seems like the thing to do if Java is free.  I
> can understand not doing it right off the bat, but it's been years
> now...
>
> geir
>
>

--
--
Frans Thamura
Meruvian Group
One Stop Java and Enterprise OSS Provider
Technopreneurship, Training, Internship, Outsourcing and Corporate
Competency Center

Mobile: [phone]
Blog & Profile: http://frans.thamura.info

Training JENI, Medallion (Alfresco, Liferay dan Compiere).. buruan...
URL: http://nagasakti.mervpolis.com/roller/mervnews/entry/jeni_training_compiere_dan_alfresco

[Dalibor Topic]

Geir Magnusson Jr. wrote:
>> * they contain Sun's own proprietary code that has not been / could not
>> be opened up so far
>
> Like what?  And why can't it be opened up?
The old plugin, for example. One could go and invest money and time into
readying it up for an open source release, but from an economic
perspective, given that the code has been rewritten for 6u10, it may be
hard to justify spending resources to do the legal and technical work on
liberating the old plugin, I think.
>> b) deployment code:
>
> Seriously though... why not just OSS it?
Companies traditionally have processes, accountability, and all that
interesting stuff, which all take a little while to maneuver through to
make sure the right things happen in the right way with all the right
people participating.

Given that the new deployment code wasn't started and developed in the
open, it means a lot of the decisions that may appear obvious from
outside have to be made explicitly and carry a non-trivial
implementation cost, for example in lawyer-time, or syncing between
OpenJDK 7 and Closed 6 - so there is a pretty good economic argument to
be made for finishing off the work on 6u10 first, and getting the new
deployment code out of 'beta', before a decision to push it into the
OpenJDK 7 tree can be made.

> Is the latter true?  I've never been able to grok where the JDK 7
> stuff comes from.  I'd have thought all work would be done out here in
> the opendjk community (after all, it's been *years* since Sun
> announced the project...) but...
The encumbered third party stuff will need to linger around for the life
time of Closed 6, and that implies some Sun repo where the maintenance
work on the encumbered stuff is done, and feeds into Closed 6 releases
containing it.

The IcedTea repo serves as a nice staging ground for code heading for
OpenJDK, among other things, and takes some pressure off Sun's back to
get things right immediately all the time. As the FSF has found out with
GNU Classpath, it's really useful to have a set of sister projects that
can juggle different tasks - and IcedTea is doing a great job of
providing the playground for patches from GNU/Linux distributions.

> I don't know about VisualVM, but the rest is free/open  software.  Why
> not just include those as well?
The focus of OpenJDK 6 so far has been to get it into a state where it
can be taken and successfully pass the compatibility tests as
unencumbered free software. So adding software that does not directly
aid that task wasn't particularly important - though given that they are
all free software, including Visual VM, there is nothing preventing
others to do it.
> So why not jettison the 3rd party code and focus the community around
> the open/free stuff?
That's what OpenJDK 6 has done, indeed.

cheers,
dalibor topic

[Mark Wielaard]

Hi Geir,

On Sat, 2008-09-13 at 10:02 -0400, Geir Magnusson Jr. wrote:

> On Sep 13, 2008, at 9:44 AM, Dalibor Topic wrote:
> > Meanwhile, the IcedTea project augments the OpenJDK jdk6 project with
> > independent implementations
> > of the plugin and webstart, called gcjwebplugin and netx. Those
> > independent implementations have a different
> > set of strengths and weaknesses from Sun's implementations: they  
> > work on 64 bit Linux, for example, a platform
> > that hasn't been supported by Sun's own plugin yet. On the other hand,
> > gcjwebplugin currently lacks an
> > adequate Java-JavaScript integration that's required by some applets  
> > to execute as well as expected.
>
> Seems like Sun is using IcedTea as a kind of "shadow project"?  I  
> don't follow things closely anymore, but someone was asking me about  
> this the other day and I couldn't really explain it clearly.   I find  
> the whole thing baffling.

It really isn't that mysterious. It is just a couple of us guys and
girls having fun with hacking on and assembling some free software
stuff, mostly based around OpenJDK and for a large part consisting of
people who have also been involved with other free software java
projects for GNU/Linux like GNU Classpath, cacao, kaffe, gcj, etc.
There is nothing "shadowy" about it, just look at
http://icedtea.classpath.org/

In a way you can see it as an continuation of all the ideas which we
shared around GNU Classpath. Creating a large, enthusiastic bunch of
people, communities and companies working on all aspects of libre java,
working together in harmony.

> > Sun's Java SE 6 download comes with a lot of (third party) software
> > bundled in, for example
> > Java DB, Rhino, Visual VM, etc. OpenJDK jdk 6 project leaves such
> > software out as much as possible,
> > concentrating on the necessities required for a compatible
> > implementation of Java SE 6.
>
> I don't know about VisualVM, but the rest is free/open  software.  Why  
> not just include those as well?

We do. IcedTea comes with applet plugins, based on gcjwebplugin and
Deepak is now extending the new IcedTeaPlugin with
LiveConnect/JavaScript support (./configure --enable-gcjwebplugin
or ./configure --enable-liveconnect). I recently added javax.script
javascript support through Rhino (./configure --with-rhino). And Joshua
added VisualVM integration (./configure --enable-visualvm), although
that drags in a big piece of NetBeans (also under the GPL now), so we
are looking at how to package that easier/separately. I believe the only
thing not integrated yet is JavaDB, but I don't really know any programs
using that. If there actually are, we can certainly add that to the mix.

As extras IcedTea also comes with cacao integration as replacement for
hotspot on those platforms that hotspot hasn't been ported to
(./configure --with-cacao). And Zero as hotspot based interpreter
(./configure --enable-zero) and shark a jit backend for hotspot still in
development (./configure --enable-shark).

> So why not jettison the 3rd party code and focus the community around  
> the open/free stuff?  Seems like the thing to do if Java is free.

That has been and always will be the goal. Sun (or any company really)
cannot do it all alone (maybe partly crippled by some of those business
decisions you mention), and that is why we are here to help out wherever
we can and provide us all with a completely free Java implementation,
integrated well, and as free as you would expect from anything bundled
with a GNU/Linux distro.

Cheers,

Mark

[David Herron-2]

Dalibor Topic wrote:

> Geir Magnusson Jr. wrote:
>  
>>> * they contain Sun's own proprietary code that has not been / could not
>>> be opened up so far
>>>      
>> Like what?  And why can't it be opened up?
>>    
> The old plugin, for example. One could go and invest money and time into
> readying it up for an open source release, but from an economic
> perspective, given that the code has been rewritten for 6u10, it may be
> hard to justify spending resources to do the legal and technical work on
> liberating the old plugin, I think.
>  
>>> b) deployment code:
>>>      
>> Seriously though... why not just OSS it?
>>    
> Companies traditionally have processes, accountability, and all that
> interesting stuff, which all take a little while to maneuver through to
> make sure the right things happen in the right way with all the right
> people participating.
>
> Given that the new deployment code wasn't started and developed in the
> open, it means a lot of the decisions that may appear obvious from
> outside have to be made explicitly and carry a non-trivial
> implementation cost, for example in lawyer-time, or syncing between
> OpenJDK 7 and Closed 6 - so there is a pretty good economic argument to
> be made for finishing off the work on 6u10 first, and getting the new
> deployment code out of 'beta', before a decision to push it into the
> OpenJDK 7 tree can be made.
>  

As was answered a couple days ago there isn't a specific plan at this
time to open source either the new or old plugin/JWS.

However it sure seems that the most expedient path is for the new
plugin/JWS to be open sourced and not bother to open source the old
plugin/JWS.  It takes a tremendous amount of time and people resources
to work through the open sourcing process.

There are other 3rd party encumbrances used to build the ClosedJDK6/7
code.  I don't have a precise list of them but if you had studied the
binary plugs we shipped last year it should give you a hint or two about
the nature of those 3rd party encumbrances. (graphics, fonts, sound,
SNMP, ...)

Among the consideration of 3rd party encumbrances is whether an open
source equivalent is a) available, b) as good quality, c) has as small a
footprint, d) executes as rapidly, e) has as few security holes, ...

>> Is the latter true?  I've never been able to grok where the JDK 7
>> stuff comes from.  I'd have thought all work would be done out here in
>> the opendjk community (after all, it's been *years* since Sun
>> announced the project...) but...
>>    
> The encumbered third party stuff will need to linger around for the life
> time of Closed 6, and that implies some Sun repo where the maintenance
> work on the encumbered stuff is done, and feeds into Closed 6 releases
> containing it.
>  

It's not just ClosedJDK6 which would continue having encumbered 3rd
party code.  Until there are encumbrance replacements which are as good
as the encumbered code it will continue to appear to be "better" to use
the encumbered code in the productized JDK build.
>> I don't know about VisualVM, but the rest is free/open  software.  Why
>> not just include those as well?
>>    
http://visualvm.dev.java.net

[Geir Magnusson Jr.-3]

On Sep 13, 2008, at 11:18 AM, Dalibor Topic wrote:

> Geir Magnusson Jr. wrote:
>>> * they contain Sun's own proprietary code that has not been /  
>>> could not
>>> be opened up so far
>>
>> Like what?  And why can't it be opened up?
> The old plugin, for example. One could go and invest money and time  
> into
> readying it up for an open source release, but from an economic
> perspective, given that the code has been rewritten for 6u10, it may  
> be
> hard to justify spending resources to do the legal and technical  
> work on
> liberating the old plugin, I think.

Oh.  That makes sense, assuming the re-written plugin is OSS.  Is it?

>
>>> b) deployment code:
>>
>> Seriously though... why not just OSS it?
> Companies traditionally have processes, accountability, and all that
> interesting stuff, which all take a little while to maneuver through  
> to
> make sure the right things happen in the right way with all the right
> people participating.

/me scratches head

Believe it or not, I *am* familiar with companies, processes,  
accountability and "all that interesting stuff".

You didn't really answer the question there...

>
>
> Given that the new deployment code wasn't started and developed in the
> open, it means a lot of the decisions that may appear obvious from
> outside have to be made explicitly and carry a non-trivial
> implementation cost, for example in lawyer-time, or syncing between
> OpenJDK 7 and Closed 6 - so there is a pretty good economic argument  
> to
> be made for finishing off the work on 6u10 first, and getting the new
> deployment code out of 'beta', before a decision to push it into the
> OpenJDK 7 tree can be made.

I feel like I'm playing 3 card monty.

So let me see if I have this right.  you took the java 6 codebase, and  
put the VM out under GPL and the libraries out under GPL+Classpath.  
You seem to have shoved one version (which I'll call "JDK Next" since  
I don't really want to dignify the unitary decision to call it "JDK 7"  
since there is no JSR for Java 7) into hg, and another (version 6) you  
keep behind closed doors, emitting bundles of source every now and  
then.    Then, is there also another  complete tree for java 6 for the  
sun product release of j6?

This seems nutty, companies, processes, accountability and "all that  
interesting stuff" notwithstanding.

Why not do continuing maintenance of j6 in the open and push the code  
into the secret j6 repo and the JDK Next repo?   I thought when java  
went open, you'd bring internal development of java at Sun out into  
the open.

I could be you do this and I'm just missing it - but on the openjdk  
site page, I only see a link to mercurial for java Next (aka "7")

>
>
>> Is the latter true?  I've never been able to grok where the JDK 7
>> stuff comes from.  I'd have thought all work would be done out here  
>> in
>> the opendjk community (after all, it's been *years* since Sun
>> announced the project...) but...
> The encumbered third party stuff will need to linger around for the  
> life
> time of Closed 6, and that implies some Sun repo where the maintenance
> work on the encumbered stuff is done, and feeds into Closed 6 releases
> containing it.

Why not just keep the encumbered code in the closed repo, taking the  
rest from an open repo?  you can do all sorts of fun and fancy tricks  
with svn and git for things like this.  I'm guessing hg can do it as  
well.

>
>
> The IcedTea repo serves as a nice staging ground for code heading for
> OpenJDK, among other things, and takes some pressure off Sun's back to
> get things right immediately all the time. As the FSF has found out  
> with
> GNU Classpath, it's really useful to have a set of sister projects  
> that
> can juggle different tasks - and IcedTea is doing a great job of
> providing the playground for patches from GNU/Linux distributions.

Why not just get people to bring changes directly to the project?  And  
how do contributions happen?  I know sun wants joint copyright of  
everything - is icedtea securing copyright for transfer to Sun?

Doesn't this take the pressure off sun to build a community?

>
>
>> I don't know about VisualVM, but the rest is free/open  software.  
>> Why
>> not just include those as well?
> The focus of OpenJDK 6 so far has been to get it into a state where it
> can be taken and successfully pass the compatibility tests as
> unencumbered free software. So adding software that does not directly
> aid that task wasn't particularly important - though given that they  
> are
> all free software, including Visual VM, there is nothing preventing
> others to do it.

I see - thx.

>
>> So why not jettison the 3rd party code and focus the community around
>> the open/free stuff?
> That's what OpenJDK 6 has done, indeed.

Ah, ok.  I'll go try to build it and see.

Thanks for the info.

geir

[Geir Magnusson Jr.-3]

On Sep 13, 2008, at 2:36 PM, David Herron wrote:

> Dalibor Topic wrote:
>>
>> Given that the new deployment code wasn't started and developed in  
>> the
>> open, it means a lot of the decisions that may appear obvious from
>> outside have to be made explicitly and carry a non-trivial
>> implementation cost, for example in lawyer-time, or syncing between
>> OpenJDK 7 and Closed 6 - so there is a pretty good economic  
>> argument to
>> be made for finishing off the work on 6u10 first, and getting the new
>> deployment code out of 'beta', before a decision to push it into the
>> OpenJDK 7 tree can be made.
>>
>
> As was answered a couple days ago there isn't a specific plan at  
> this time to open source either the new or old plugin/JWS.
>
> However it sure seems that the most expedient path is for the new  
> plugin/JWS to be open sourced and not bother to open source the old  
> plugin/JWS.  It takes a tremendous amount of time and people  
> resources to work through the open sourcing process.

I know.. i've been there :)

But why did you do the new plugin behind closed doors in the first  
place?  Seems like doing out in the community would have been the  
better route...

geir

[Dalibor Topic-5]

Geir Magnusson Jr. wrote:
> Why not do continuing maintenance of j6 in the open and push the code
> into the secret j6 repo and the JDK Next repo?
Because OpenJDK 6 came after OpenJDK 7 which came after SE 6.

OpenJDK 7 is where the development of 7 is happening, while OpenJDK 6
has been created to deliver a stable, certifiable
implementation of SE 6 in collaboration with GNU/Linux distributions, as
it makes a lot more sense for a distributor to ship
a stable SE 6 API and implementation then one in heavy development, i.e.
7, and a lot of distributors have a strong preference
for a fully free software implementation, i.e. OpenJDK 6 based ones.

Yeah, it's a bit messier than one would expect, but it should become
simpler over time.

> Why not just get people to bring changes directly to the project?
They do, too. One does not exclude the other. ;)
>   And how do contributions happen?
On the lists.
> I know sun wants joint copyright of everything - is icedtea securing
> copyright for transfer to Sun?
The patches going into OpenJDK are covered by SCA, yes. Not all patches
need to go into OpenJDK, though,
so IcedTea does not require the SCA for contributions.
> Doesn't this take the pressure off sun to build a community?
The OpenJDK community goes beyond a single organization or project.
Naturally, Sun is contributing a lot
to help grow OpenJDK, and so far seems to be doing it all a lot better
then some would have expected initially.

That's in large part due to the community OpenJDK attracted so far
coming from a long tradition of successful,
distributed open source development around independent projects like GNU
Classpath - those developers
don't have a habit of waiting for Sun to do one thing or another - as
IcedTea shows, the community goes
ahead and does things that it needs to be done, like pull up additional
ports, or provide a plugin on
amd64-linux, etc.

I think it's been working out pretty good overall - instead of the team
at Sun trying to build an
open source Java SE community from scratch, it was courageous enough to
try to mesh with the
existing one instead, and that has paid off.

There is still a ton of things to do, of course. There always is.

cheers,
dalibor topic

--
*******************************************************************
Dalibor Topic                   Tel: [phone]
Java F/OSS Ambassador           AIM: robiladonaim
Sun Microsystems GmbH           Mobile: [phone]
Nagelsweg 55                    http://openjdk.java.net
D-20097 Hamburg                 mailto:Dalibor.Topic@...
Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
Amtsgericht München: HRB 161028
Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
Vorsitzender des Aufsichtsrates: Martin Häring

[Mark Wielaard]

Hi Geir,

On Sat, 2008-09-13 at 15:20 -0400, Geir Magnusson Jr. wrote:

> So let me see if I have this right.  you took the java 6 codebase, and  
> put the VM out under GPL and the libraries out under GPL+Classpath.  
> You seem to have shoved one version (which I'll call "JDK Next" since  
> I don't really want to dignify the unitary decision to call it "JDK 7"  
> since there is no JSR for Java 7) into hg, and another (version 6) you  
> keep behind closed doors, emitting bundles of source every now and  
> then.    Then, is there also another  complete tree for java 6 for the  
> sun product release of j6?
>
> This seems nutty, companies, processes, accountability and "all that  
> interesting stuff" notwithstanding.

Although I am sure some of the things being done are nutty (we all have
our weird habits and we are all human after all) it seems you have
indeed not been following the developments very well.

What Sun has liberated is their jdk7 (Java the Next Generation) code
base, or at least those parts they could. Then they realised that it
would also be fun to have a fully free GPLed JDK6 implementation, so
they did what Joe called "Forward to the Past", removing anything that
wasn't in the JDK6 spec, but that was already in the JDK7:
http://blogs.sun.com/darcy/entry/forward_to_the_past

Joe has been working really hard on this all, and through IcedTea we
have helped out by trying out various alternatives to some of the still
encumbered code to make this happen. Some of those alternatives have now
made it into Joe's tree. For some reason Joe hasn't yet found the time
to put this all into a mercurial repository (remember when he started
JDK7 wasn't in mercurial also). That does indeed seem like a painful way
to work, but in the end there is only so much time in a day. In IcedTea
we do put all our work directly into a mercurial repository. I do think
that makes working together much more easier. We will get there with
openjdk6 also I hope when Joe finds the time.

Now Sun also has an old code base for JDK6, which is still completely
proprietary and which they are still maintaining, it only partly shares
code with the new OpenJDK work. So porting patches between the two isn't
as easy since the code bases don't match up and that old code base isn't
entirely encumbrance free. It does seem very painful to work in that
way. And maybe you are right that Sun is making the wrong business
decisions to keep that old legacy code base around in this form. It
certainly isn't a very interesting code base for the community at large
and you won't see a free GNU/Linux distro ship it.

Sun isn't alone in all this though. And they sure do not do everything
perfect yet. And yes, they sometimes do silly, weird things, apparently
completely missing the whole opportunity they have. But what we do as
community is help and guide Sun to do the right thing. If that means to
ignore any silly proprietary stuff and as a community provide free
alternatives to show how it is really done, then so be it. That is
precisely what we do through IcedTea, integrate and provide Free
Software alternatives for those parts where we think Sun is still
missing the point. Together we will make this work.

Cheers,

Mark

[Geir Magnusson Jr.-3]

On Sep 13, 2008, at 2:36 PM, Mark Wielaard wrote:

> Hi Geir,
>
> On Sat, 2008-09-13 at 10:02 -0400, Geir Magnusson Jr. wrote:
>> On Sep 13, 2008, at 9:44 AM, Dalibor Topic wrote:
>>> Meanwhile, the IcedTea project augments the OpenJDK jdk6 project  
>>> with
>>> independent implementations
>>> of the plugin and webstart, called gcjwebplugin and netx. Those
>>> independent implementations have a different
>>> set of strengths and weaknesses from Sun's implementations: they
>>> work on 64 bit Linux, for example, a platform
>>> that hasn't been supported by Sun's own plugin yet. On the other  
>>> hand,
>>> gcjwebplugin currently lacks an
>>> adequate Java-JavaScript integration that's required by some applets
>>> to execute as well as expected.
>>
>> Seems like Sun is using IcedTea as a kind of "shadow project"?  I
>> don't follow things closely anymore, but someone was asking me about
>> this the other day and I couldn't really explain it clearly.   I find
>> the whole thing baffling.
>
> It really isn't that mysterious. It is just a couple of us guys and
> girls having fun with hacking on and assembling some free software
> stuff, mostly based around OpenJDK and for a large part consisting of
> people who have also been involved with other free software java
> projects for GNU/Linux like GNU Classpath, cacao, kaffe, gcj, etc.
> There is nothing "shadowy" about it, just look at
> http://icedtea.classpath.org/

Ha!  I didn't mean "shadow" as in secret or sinister, but more like a  
"companion" that does the same thing.

Do you give patches back to OpenJDK?  How do you deal with the joint  
copyright thing?  I looked at the site but didn't see anything.

>
>
> In a way you can see it as an continuation of all the ideas which we
> shared around GNU Classpath. Creating a large, enthusiastic bunch of
> people, communities and companies working on all aspects of libre  
> java,
> working together in harmony.

Right - and that's great.  As you know, I'm all for Harmony ;)

I'm just wondering why all of those people don't do it at OpenJDK.

>
>
>>> Sun's Java SE 6 download comes with a lot of (third party) software
>>> bundled in, for example
>>> Java DB, Rhino, Visual VM, etc. OpenJDK jdk 6 project leaves such
>>> software out as much as possible,
>>> concentrating on the necessities required for a compatible
>>> implementation of Java SE 6.
>>
>> I don't know about VisualVM, but the rest is free/open  software.  
>> Why
>> not just include those as well?
>
> We do. IcedTea comes with applet plugins, based on gcjwebplugin and
> Deepak is now extending the new IcedTeaPlugin with
> LiveConnect/JavaScript support (./configure --enable-gcjwebplugin
> or ./configure --enable-liveconnect). I recently added javax.script
> javascript support through Rhino (./configure --with-rhino). And  
> Joshua
> added VisualVM integration (./configure --enable-visualvm), although
> that drags in a big piece of NetBeans (also under the GPL now), so we
> are looking at how to package that easier/separately. I believe the  
> only
> thing not integrated yet is JavaDB, but I don't really know any  
> programs
> using that. If there actually are, we can certainly add that to the  
> mix.
>
> As extras IcedTea also comes with cacao integration as replacement for
> hotspot on those platforms that hotspot hasn't been ported to
> (./configure --with-cacao). And Zero as hotspot based interpreter
> (./configure --enable-zero) and shark a jit backend for hotspot  
> still in
> development (./configure --enable-shark).
>
>> So why not jettison the 3rd party code and focus the community around
>> the open/free stuff?  Seems like the thing to do if Java is free.
>
> That has been and always will be the goal. Sun (or any company really)
> cannot do it all alone (maybe partly crippled by some of those  
> business
> decisions you mention), and that is why we are here to help out  
> wherever
> we can and provide us all with a completely free Java implementation,
> integrated well, and as free as you would expect from anything bundled
> with a GNU/Linux distro.

That's great!  I'm just curious why it couldn't have been done in the  
OpenJDK project.

Thanks

geir

>
>
> Cheers,
>
> Mark
>

[Geir Magnusson Jr.-3]

On Sep 13, 2008, at 4:21 PM, Dalibor Topic wrote:

> Geir Magnusson Jr. wrote:
>> Why not do continuing maintenance of j6 in the open and push the code
>> into the secret j6 repo and the JDK Next repo?
> Because OpenJDK 6 came after OpenJDK 7 which came after SE 6.

Remember that 3 card monty thing? :)

How could ....  oh, never mind.

>
>
> OpenJDK 7 is where the development of 7 is happening, while OpenJDK 6
> has been created to deliver a stable, certifiable
> implementation of SE 6 in collaboration with GNU/Linux  
> distributions, as
> it makes a lot more sense for a distributor to ship
> a stable SE 6 API and implementation then one in heavy development,  
> i.e.
> 7, and a lot of distributors have a strong preference
> for a fully free software implementation, i.e. OpenJDK 6 based ones.

But "Java 7" was the Java 6 code, right?  why would 6 come after 7?

>
>
> Yeah, it's a bit messier than one would expect, but it should become
> simpler over time.
>
>> Why not just get people to bring changes directly to the project?
> They do, too. One does not exclude the other. ;)
>>  And how do contributions happen?
> On the lists.

iced-tea lists?

>
>> I know sun wants joint copyright of everything - is icedtea securing
>> copyright for transfer to Sun?
> The patches going into OpenJDK are covered by SCA, yes. Not all  
> patches
> need to go into OpenJDK, though,
> so IcedTea does not require the SCA for contributions.

So what happens when something in IcedTea needs to go back into  
OpenJDK?  Has that actually happened?

>
>> Doesn't this take the pressure off sun to build a community?
> The OpenJDK community goes beyond a single organization or project.
> Naturally, Sun is contributing a lot
> to help grow OpenJDK, and so far seems to be doing it all a lot better
> then some would have expected initially.
>
> That's in large part due to the community OpenJDK attracted so far
> coming from a long tradition of successful,
> distributed open source development around independent projects like  
> GNU
> Classpath - those developers
> don't have a habit of waiting for Sun to do one thing or another - as
> IcedTea shows, the community goes
> ahead and does things that it needs to be done, like pull up  
> additional
> ports, or provide a plugin on
> amd64-linux, etc.
>

But then if they're doing it "over there", how does that make them  
part of the community "over here"?

I'm really not trying to be argumentative :)  I'm just trying to grok  
what is real and what is "promotion".

> I think it's been working out pretty good overall - instead of the  
> team
> at Sun trying to build an
> open source Java SE community from scratch, it was courageous enough  
> to
> try to mesh with the
> existing one instead, and that has paid off.

Oh, come now :)  They are meshing with part of the OSS Java SE  
community one one hand,  and - forgive me for being blunt - using  
patent-based licensing restrictions to try to strangle (or, as MSFT  
would phrase it, "cut off the air supply" ) another.

I'm glad it's paying off for you.  Is there a certified, non-sun java  
se impl yet?

geir