Skip to main content

It will be (Open)JDK7 where OpenJDK==JDK

Posted by robogeek on January 5, 2009 at 2:48 PM PST

I'm listening to the 'holidays 2008ish' episode of Javaposse and in reviewing their last years predictions they have enough fumbling around the status of OpenJDK that I want to do a little bit of explaining.

OpenJDK 6 != JDK 6

There are circuitous historical reasons for this but the fact is that OpenJDK 6, as good as it is, does not correspond to JDK 6uN for any value of N. OpenJDK 6 began as a fork of OpenJDK 7, and the team stripped out code from the OpenJDK 7 fork until it became compatible with the Java6 specification as verified by the JCK 6 test suite.

Joe Darcy has posted several blogs about this OpenJDK 6 Genealogy, OpenJDK 6 and 6u10 features, OpenJDK 6: Logistics of Partial Merge with 6u10, and the most important of these is: Forward to the Past: Toward OpenJDK 6

If you're scratching your head going "huh??", well, I don't blame you, just read Joe Darcy's blog postings and it will be clear as, well, uh, I just hope it's clear why.

The bottom line is that OpenJDK 6 works rather well, several Linux distros are using it as their JDK, it can be built to pass the JCK6b test suite, meaning OpenJDK 6 can be used to build a compliant JDK, and unfortunately it is this evolutionary sidetrack which we hope will be relatively short-lived. It serves a purpose, namely of having an fully open OpenJDK compliant with Java6 ....

OpenJDK ~=~ IcedTea

It seems some people really like typing "./configure" rather than setting up environment variables and running "make". The IcedTea project originally began due to incompleteness in the OpenJDK (gaps due to encumbrances) and the community requirement of a fully open source toolchain and code base. IcedTea has long been a set of patches applied to OpenJDK, along with a different build system that is "./configure" based as I just said.

In OpenJDK we've replaced the encumbered code such that there are no gaps any longer. As we've done so I believe the IcedTea project has shrunken the number of patches they use. One nice thing seems to be that the IcedTea configure script makes it easy to build OpenJDK in many different modes such as using the Zero Assembler port to support compiling on non-x86/sparc chipsets, etc.

A big piece IcedTea provides is a plugin/java-web-start infrastructure. We haven't been able to open source our plugin and of course for 6u10 we completely rewrote the plugin. It is hoped we will open source the new plugin into the OpenJDK project but to my knowledge that decision has not been made concrete set in stone.

I don't spend much of my time looking at IcedTea so don't be alarmed if I've missed something ...

OpenJDK 7 == JDK 7

Okay, given that there is not a Java7 JSR and all the JCP stuff related to that issue ... Hopefully all that will be straightened out and we do have a proper Java7 JSR, so for the following please assume that's the case, that Java7's JSR status is straightened out ... the plan is that beginning with OpenJDK7/JDK7 that the code bases will be nearly identical. It is obviously expensive to maintain a fork, and if JDK7 were to diverge strongly from OpenJDK7 it would do two things: a) be very expensive, b) undermine our efforts at an open source ecosystem.

But "nearly identical" does mean it's likely there will be some differences.

Remember those gaps due to encumbrances? Some of those gaps were simply code we couldn't open source as of May 2007 but have since done so, other gaps are for code we still have to gain approval on (e.g. SNMP), but there is some code where there are open source replacements where we still use the old closed source code. This is primarily in font and graphics rasterization. The old closed source rasterisation code, while being encumbered, has had 10+ years of bug fixing and fine tuning etc and, for any open source replacement to displace that code in productized JDK builds, it would have to be provably as fast and stable and good quality as the existing closed code.

What took so long?

If we had followed normal release patterns JDK7 would be shipping about now. That is, Java6 shipped in December 2006 and our normal pattern is 18-24 months between major releases meaning the JDK7 launch would have been 2-5 months ago. What happened? Well, clearly there was a resource crunch on several angles.

For example getting the nearly complete OpenJDK source release in May 2007 took a lot of effort from lots of people. But there was also certain announcements at JavaONE in May 2007 (a little thing named JavaFX) which also turned into a major rethink of Java (as some have said, this ain't yer Dad's Java) and also a major piece of work to accomplish.

In other words instead of producing JDK7 we did JDK6u10 and JavaFX.

Related Topics >>


@david, nim_nim I think the main reason why open source projects or libraries will NEVER be integrated into OpenJDK is not quality, but it's a pure licensing issue. You will probably never get an Open Soure project (er even worse, all the contributors to an Open Source project) to sign the Sun Contributor Agreement (SCA). But without SCA, no integration into OpenJDK!!! And the reason is clear: as you mentioned, Sun want's to keep OpenJDK X and SUN JDK X as close as possible ("nearly identical") - otherwise this will "be very expensive"! The only money Sun is currently earning with Java is from commercial Licensees, and they expect to get Java sources under commercial licenses. So the closed, proprietary library will remain in the JDK! As sad as this sounds, I think even if an "Open" solution would be an order of magnitude better compared to its counterpart in the closed JDK, it will not become part of OpenJDK/JDK because of the reasons mentioned above. Hopefully, projects like IcedTea, OpenJDK6 and the OpenJDK clones shipped by various Linux contributors will put enough pressure on Sun (if they become superior for example in font handling) to change this situation. Regards, Volker

The fact seem to be pessimism. As you white above that ......and the team stripped out code from the OpenJDK 7 fork until it became compatible with the Java6 specification as verified by the JCK 6 test suite. with JDK7 release, the performance and stability may more improving on side of swing and Java2D?

@david The first step in moving to cairo is to just use the freetype backend which is available now in openjdk. And I was responding to the fallacy that consists to pretend current java font support is good (it isn't) and alternatives are unproven (they aren't). Years of half-hearted font support while SUN was focusing on server-side java does not make a wondrous codebase. Can it even handle yet the OTF fonts everyone from proprietary foundries to open font projects produces nowadays ? So, "10+ years of bug fixing and fine tuning". That's one way to put it.

@nim_nim: There are some somewhat related projects on, 'Graphics Rasterizer' and 'XRender' and 'Cacciovalo' (?sp?). The story you lay out for Cairo is very tempting from the same 10,000 foot level you accuse me of living on. It's quite possible to launch an openjdk project to rejigger the graphics & font rasterization to use cairo. We have adopted freetype for the openjdk (but not closedjdk). I suggest that the first step to convincing us to use this in closedjdk is to implement it in openjdk so that we have a concrete thing to discuss.

> This is primarily in font and graphics rasterization. The old closed source rasterisation > code, while being encumbered, has had 10+ years of bug fixing and fine tuning etc and, > for any open source replacement to displace that code in productized JDK builds, it would > have to be provably as fast and stable and good quality as the existing closed code. This sounds reasonable and PFB-friendly except the kindest words one could ever write about java font handling were "quirky" "buggy" and "ugly", it forgets font formats and unicode have and still are evolving (so an historic rasterizer does you no good without continuous updating and maintenance), and that also papers over the fact that the alternative is to just use the same font software stack as Firefox,, GNOME, KDE, and countless others. Between them they represent a bigger multi-platform text test base than java ever had (because an awful lot of java users never cared about its text rendering, another big part cared but resignated itself to its crappy state, while good text rendering is a MUST for a browser or office suite). True, still has a few peculiarities but is moving away from them as its historic codebase is increasingly lagging behind cairo in terms of modern opentype support (last I've looked java was worse). But it has adopted fontconfig and freetype for quite a few years already. Do yourself and your users a favour and use the same font/text libs (cairo, pango, freetype, fontconfig) everyone else has been converging on. Java needs proper text handling not to condemn its new attempt at desktop-friendliness.

"In other words instead of producing JDK7 we did JDK6u10 and JavaFX." ... only question is why didn't you name it Java 6.1 (or 6.5) instead of the pretty obscure JDK6u10.

OK, I'll take you word for it on the effort of JavaFX and 6u10 as opposed to OpenJDK. As for OpenJDK having potential for "huge significance", I've been asking what that means for years now. From what I can tell, it's produced a handful (by which I mean 5-10, but maybe it's even as high as 30) additional contributors, and Java now comes preinstalled on the few Linux distros that wouldn't do so before. As always, I'm curious about what difference that's made in terms of dollars (or mindshare, or whatever) for Sun. The Mozilla reference was toward Netscape putting their effort into open-sourcing their browser, and in doing so, spending lots of effort for no money. The company tanked, got bought out, and eventually all laid off. They did their own self-fullfilling prophecy: working to make sure their work lived on, and in doing so killed the company. So yes, Mozilla lives on and Netscape is dead, which I guess is what Netscape wanted. It seems Sun is doing the same with Java. All IMHO of course :) And as for mozilla being hugely successful, I think any company would do well when 85% of its income is a donation from google. Let's see how they do when that income stops later this year. And in any case, I think Netscape did far better than Mozilla no matter how you measure.

@atripp, this blog was purely focused on explaining the situation for OpenJDK for an explicit purpose. Because the public coverage of OpenJDK work has been minimal. Believe me that for the team overall the effort has been highly skewed to JavaFX and 6u10, if you want a taste of that side of the story I suggest you find the podcast named 'This Ain't Your Dad's Java" and listen to the episodes.

As for the relative benefits of these different projects, I too have my doubts. But I am very clear on one thing. That the OpenJDK has potential for huge significance. I am hoping that we at Sun can get our act in gear for cooperation with IcedTea and others before its too late.

I really don't understand your reference to mozilla. Today the mozilla project is hugely successful but of course the early years of mozilla were pretty doubtful.

> For example getting the nearly complete OpenJDK source release in May 2007 took a lot of effort from lots of people. It's nice to see you acknowledge that the OpenJDK effort is, at least in part, responsible for there being no JDK7. But then you say... > In other words instead of producing JDK7 we did JDK6u10 and JavaFX. From outside of Sun, it sure looks like more effort is going into making Java open than into JavaFX and JDK6u10. This blog is a perfect example - almost entirely on OpenJDK. Now might be a good time to look back and see if the time was well spent. How many developers will benefit from JavaFX, how many from JDK6u10, and how many from OpenJDK? How many would have benefitted from JDK7? I'd also recommend thinking hard about the size of IcedTea. You assumed that it's shrinking, and gnu_andrew points out that it's actually growing. Maybe it's time to question all the things that people were saying about IcedTea: It's temporary, its changes would get folded into Java, it will increase the size of the Java community. And it's always a good time to think about whether the OpenJDK work has helped or hurt Sun's bottom line. I think Sun has Mozilla-ed itself ;)

Before somebody complains that Java 7 is late, I for one consider 6u10 a massively important update - it's great that, for a change, we have an update that just makes Java faster and better, without any growing of footprint, APIs or other aspects. Besides that, it wouldn't be possible to have JDK 7 finished by now because the discussion of some new language features was a drag (unfortunately with a bad outcome - we're apparently not having closures or properies for this release). The invokedynamic stuff was also more difficult to get right and much expanded by the MLVM project; and fortunately in this case it's shaping to be a huge win of Java 7.

I second Andrew's post and would like to add that IcedTea plays an important role when attempting to cross-compile OpenJDK (including a complete source-based toolchain bootstrap). Details: I am curious to see what the future brings in regards to OpenJDK7. :-)

Nice blog; I think this is something that comes up a lot and does need clarifying. Of course, what I hope is we get into a situation where we just have OpenJDK eventually, but I can't see that happening until 7 is released and that's assuming the two divergent 7 trees become one by that time. To clarify a few things on IcedTea: * IcedTea still uses the OpenJDK build system, it just saves you time by working out what all those make variables should be and making sure you have everything before you get halfway through the build... * IcedTea has grown rather than shrunk - while we've been able to drop a lot of the plug replacements, it now plays host to a lot of patches along with the plugin/javaws support, and zero/shark/cacao vm replacements. We're also now using a newer HotSpot release. * It's really two equations: OpenJDK \subset IcedTea OpenJDK 6 \subset IcedTea6 i.e. there's an IcedTea 6 that matches OpenJDK 6, and an IcedTea that matches OpenJDK. Things work the opposite to OpenJDK, as most development work goes into IcedTea6 rather than IcedTea. IcedTea primarily just tracks the new JDK7 build drops and pulls in changes from IcedTea6 periodically. I also see the relationship as less an equality one and more of a OpenJDK being a subset of what's in IcedTea. We now add quite a bit of stuff that's not provided by OpenJDK (like tripling the architecture support). * As far as the plugs go - it's true you can now build OpenJDK6 without proprietary plugs by setting a variable (I don't know why this isn't just the default though), but this isn't true of OpenJDK7. Also, it still isn't possible to bootstrap OpenJDK without an existing IcedTea build (e.g. with GNU Classpath + ecj as we do in IcedTea). This is more a difference in approach than any technical problem IMO. For us, relying on proprietary software to build by default is not an option and this is still the case for both OpenJDK6 and 7.