Sun JDK vs OpenJDK - Sun JRE vs OpenJDK JRE

Andrew John Hughes gnu_andrew at
Sun Sep 14 01:14:36 UTC 2008

2008/9/13 Dalibor Topic <Dalibor.Topic at>:
>> So what happens when something in IcedTea needs to go back into OpenJDK?
> It gets submitted to the corresponding project's mailing list for review
> (for example the build-dev mailing list for build patches),
> gets reviewed, and if the SCA isn't signed, the submitter signs the SCA
> and then the patch eventually goes in.
>> Has that actually happened?
> It happens regularly, yes, of course. Please see the release notes for
> OpenJDK 6 builds for details.

For minor bug fixes, yes.  Not for anything really substantial, and what
has gone through has been slow.  IcedTea still has 80 odd patches,
though not all of them would be candidates for upstream.  Things are
even worse with the OpenJDK tree (that's the
will-be-maybe-sometime-never-jdk7 tree).

The recent establishment of an 'OpenJDK infrastructure' has meant
that some autonomous projects and code trees have appeared with
Sun hosting mainly from the challenge process e.g. caciocavallo,
(Roman and Mario's AWT work) and closures, but also the BSD port.
Again, these are based on the '7' tree.  There is still no OpenJDK6 tree.

>> But then if they're doing it "over there", how does that make them
>> part of the community "over here"?
> IcedTea development mailing list is the OpenJDK mailing list
> distro-pkg-dev. The bugzilla and mercurial server
> used by IcedTea are not hosted by OpenJDK though, they have been created
> before OpenJDK had corresponding
> infrastructure in place (and the bugzilla instance is not there yet, for
> example). A lot of IcedTea development also
> makes its way into the upstream OpenJDK 6 builds, so it goes out on
> corresponding OpenJDK project mailing lists.

I think that's pushing things a little in the name of making the point.
Sun and the IcedTea community still seem very separate and distinct to me,
even if we happen to have a mailing list hosted as part of
The patches seem to have largely been handled as individual contributions,
not as from the IcedTea projects.  Joe's work on OpenJDK6 is an exception to
this rule, and I praise his solo work on this tree and his explicit
referencing of
IcedTea patches.  But clearly Sun's commitment to OpenJDK6, the version
used as the base for every distro version, only runs to one employee
as far as we can see.

> I know this sounds very confusing to people used to drawing gates around
> communities - the squishy concept
> of a community of communities around a shared backbone is something that
> OpenJDK has adopted from GNU
> Classpath, where it has worked really nicely to enable permeable
> development.

I'm sorry, I don't see this 'community of communities', except in the
form of the existing
GNU Classpath community, who are slowly becoming the IcedTea community too.
Sun haven't integrated into this to any great extent; there is little
discussion of work
being done, just big blobs of code being dropped every so often and
lots of commits
with no rationale for them.

Sun need to open their processes more if they are going to become part
of the community.
There have been promises of this, but I've seen very little change
since JavaOne.  There is
still no bug database for example.   The most code development
apparently seems to be
still going on in a proprietary code base, making all this 'everything
will be free from now on'
mantra meaningless.

I think what IcedTea proves is that the community will carry on,
regardless of what Sun does.
That's why it has an independent bug database, independent
repositories, etc.  These things
are needed, Sun have failed to produce them and so the community has
done their own thing.
The same goes for the plugin.  To me, the Sun involvement has felt
like arbitrary blobs of code
we have to merge in to IcedTea for quite a while now, and don't think
you can call that community

At this rate, the only difference with the development of OpenJDK over
the proprietary
codebases will be that we can see every minutae, every changeset going
in.  However, we won't
have been involved in its development, just in making it fit for human
consumption.  It is solely
up to Sun when and how they choose to fix this; the community will
carry on regardless.

>> Is there a certified, non-sun java se impl yet?
> The Fedora 9 binaries on x86 and amd64 have passed the SE 6 TCK.
> Sun doesn't control what goes into those binaries, the Fedora community
> does,
> and obviously does it quite successfully.

I don't think that's what Geir meant; he just didn't word his question
correctly.  The TCK license terms
specifically require that the binaries are 'substantially derived'
from OpenJDK so
Harmony+DRLVM or GNU Classpath+something like CACAO, JamVM, GCJ or
Kaffe (remember that?)
can not meet these terms.

I don't think this is a technical requirement, but a business one as
we've already said.
And fortunately there is a hacky way of getting at least something
close to what we want
until Sun choose to sort this out properly; certify HotSpot + another
class library (GNU Classpath or Harmony),
and certify the OpenJDK class library + VM (CACAO is already someway
along this road).
It's by no means a perfect or working solution, but it means most of
the technical fixes
could be made before a true integration is made possible.

> cheers,
> dalibor topic
> --
> *******************************************************************
> Dalibor Topic                   Tel: (+49 40) 23 646 738
> Java F/OSS Ambassador           AIM: robiladonaim
> Sun Microsystems GmbH           Mobile: (+49 177) 2664 192
> Nagelsweg 55          
> D-20097 Hamburg                 mailto:Dalibor.Topic at
> Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten
> Amtsgericht München: HRB 161028
> Geschäftsführer: Thomas Schröder, Wolfgang Engels, Dr. Roland Bömer
> Vorsitzender des Aufsichtsrates: Martin Häring

Sorry if this sounds a little bitter - I'm not.  I'm just losing patience and
tired of Sun's empty promises.

Andrew :-)

Support Free Java!
Contribute to GNU Classpath and the OpenJDK

PGP Key: 94EFD9D8 (
Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8

More information about the discuss mailing list