Sun JDK vs OpenJDK - Sun JRE vs OpenJDK JRE

[David Herron]

Geir, these are really good questions ..

Geir Magnusson Jr. 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.
>
> 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")
We are in a nutty intermediate stage.

The initial openjdk releases (as I recall, you were there) were for the 
oh-heck-let's-call-it-java-7 release ;-) ... and then later business 
decisions led us to do major work in the Java 6u<i> release train (for 
various values of 'i'), more work than we'd normally do update releases.

Given that there was a desire/need for a Java6 compatible OpenJDK the 
question would be.. how to get there?  There were several options and 
the one we chose was to reuse the already opened source tree and, as Joe 
termed it, make reverse progress into the future.  That is, to derive a 
Java6 compatible tree from the oh-heck-let's-call-it-java-7 tree and if 
it were to pass JCK6a (now JCK6b) then it's good to go.

Another little detail was the timing of mercurial repositories.  The 
mercurial switchover did not happen until IIRC openjdk7b23 however the 
reverse progress openjdk6 plan was a fork of openjdk7b20 which means 
openjdk6 was not in mercurial.

There used to be a tarball release for the oh-heck-let's-call-it-java-7 
tree but in b23 we made the mercurial switch.  In fact the page for the 
tarballs is still there, and it's updated with the latest drop.  While 
it does have a tarball the primary purpose for that page is the binary 
plugs..

http://download.java.net/openjdk/jdk7/
> 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.
This is actually very close to what we do for the 
oh-heck-let's-call-it-java-7 release ;-)

There's the openjdk7 repository and inside the firewall a closedjdk7 
repository.  The closedjdk7 repository is just the encumbered bits. 

Where the repository paths on hg.openjdk.java.net are: jdk7/jdk7/{comp}
On closedjdk.sfbay.sun.com the repository paths are: 
jdk7/jdk7/{comp}/{make,src,test}/closed
Further some components do not have closed counterparts, it appears only 
the hotspot and jdk components have closed counterparts.

You can see that if you have an openjdk7 source tree and then drop on 
top of it the closedjdk7 code it will fall into "closed" directories 
without touching the openjdk7 part. 

If you have a checked out openjdk7 repository this command should be 
instructive:-

$ find jdk7 -type f \( -name Makefile -o -name '*.gmk' -o -name '*.defs' 
\) -print | xargs grep closed


- David Herron