Sun JDK vs OpenJDK - Sun JRE vs OpenJDK JRE
Geir Magnusson Jr.
geir at pobox.com
Sat Sep 13 07:02:46 PDT 2008
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
> 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
> 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
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
> 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
> 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
More information about the discuss