Sun JDK vs OpenJDK - Sun JRE vs OpenJDK JRE

[Geir Magnusson Jr.]

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