Sun JDK vs OpenJDK - Sun JRE vs OpenJDK JRE
Geir Magnusson Jr.
geir at pobox.com
Sat Sep 13 19:20:26 UTC 2008
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
> readying it up for an open source release, but from an economic
> perspective, given that the code has been rewritten for 6u10, it may
> 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
> 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
> 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
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
>> 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
> 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
> 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
> GNU Classpath, it's really useful to have a set of sister projects
> 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.
>> 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
> 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.
More information about the discuss