Sun JDK vs OpenJDK - Sun JRE vs OpenJDK JRE
robilad at kaffe.org
Sat Sep 13 15:18:32 UTC 2008
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
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
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.
More information about the discuss