Tags: OpenJDK
It's the last day of JavaONE, I spent most of my time in the OpenJDK booth talking with people. And their questions are on my mind. Here's a few answers to common questions.
What happens with people selling commercial apps today? Someone selling a commercial app today, they can continue doing what they're doing. Nothing changes for them if the existing licenses still works for them. The choice of license between open source and commercial offers more choices, and the tactic of dual-licensing allows the community to use it in the way that fits for them.
What about a port to X/Y/Z platform? Several asked about porting the OpenJDK code to platforms the JDK does not work on. This ranged from embedded devices to Mac OS X. Clearly embedded devices are getting powerful enough that over the next couple years we should expect to erase the boundaries between the SE and ME models. In any case, what about porting the OpenJDK code?
The technical aspect is that there are two classes of system dependent code in the JDK. You should talk with the development engineers for more information, as I rarely touch the internals. One set of system dependencies is in Hotspot, as it includes a compiler which converts classfile bits into native code instructions. For Hotspot to support a new processor architecture it needs to know how to compile native code for that processor. I'm not sure if it has a mode to fall back to pure interpretation, but I do know there is an assembly language "loop" that drives the interpretor.
The other set of system dependencies is the GUI system and other native code to interface with native system resources. In the source tree you'll find a section that's system dependent files, with a mix of source languages in each set of system dependent files. The Makefiles also have to deal with compiling the right files for the right platform.
Again, I don't work on that code very often so for more correct and complete information I suggest Using the Source, Luke.
It was most interesting, though, the number of people who asked about porting to Mac OS X, many of whom are frustrated over the situation with getting Java6 on Mac OS X. So, um, Apple is in charge of the Java implementation for OS X.... Unfortunately it seems Apple prefers to ship major upgrades of their Java implementations along with major OS upgrades, and unfortunately the impending upgrade to 10.5.x has been delayed to October. I know that's left me frustrated, what about you guys? In any case we (Sun) only shipped the final Java6 just a couple months ago, so at this point Apple is only a couple months "behind". That's really not too bad at all.
But could one port the OpenJDK to OS X? Besides the above system dependencies there is this really crucial problem. Right now building the OpenJDK requires having a binary build of the matching JDK7 release. That's due to the encumbered code, because the compiled encumbered code exists in that matching JDK7 build. Obviously there isn't a matching JDK7 build for OS X, so the OpenJDK build on OS X would have zero chance of getting anywhere useful.
What if you want to get support for a modified OpenJDK? Hmm, clearly for Sun to succeed at this one of the things we must be able to provide is services around the OpenJDK project. Dating back to the GNU MANIFESTO it's been clear a main way to earn a living on open source software is to offer services related to that software. I would think we have some support organization gearing up to provide services on the OpenJDK, but I have no clue where/how to find them. There is also the option/possibility for competition to arise in offering services on the OpenJDK. This happens with other open source projects, such as what CentOS does in relation to Red Hat Enterprise Linux.
What's the difference between the commercial and open source JDK's? They're essentially the same. This went over with the questioners in one of two ways. Some thought it was wrong that there were any differences, but clearly we have encumbrances etc which are going to represent code divergence for awhile, and also the build process is different in the commercial and openjdk releases. Others thought we had started over from scratch with a brand new project using brand new code. Hmmm... clearly that would be very expensive for us, and thankfully that's not what we're doing. On the other hand it was expensive to have all that quality time with the lawyers and trademark experts with whom we carefully studied the code to determine its origin and cleaning out trademarked stuff etc.
What's the version number of the OpenJDK? Hmm, I've not heard any specific version number. However the OpenJDK code as it stands matches the JDK7 release train. The OpenJDK code is the HEAD of the source repository. For the time being the OpenJDK releases march in lockstep with the JDK7 builds, and once we have the Mercurial repository running you'll be able to extract sources based on the tags for each release, etc. At some point towards the end of JDK7 cycle we'll branch/fork the repository so that the final stages of the JDK7 release happen in the fork, and the HEAD will transmogrify to match the JDK8 release.
So, um, you tell me what the OpenJDK version number should be. One person suggested we start with OpenJDK 1.0, but I think that would be a little confusing to have to remember the mapping between the numbers. It would be better to have the version number match the JDK version number.
What language is it written in? There is a mix of C, C++, Make, ANT, XML, and Java. There's probably more but that's what I know about.
Why did you do it? Because Jonathan and RichG told us to do it??
Seriously, if I can channel Rich Sands for a moment ... The market had matured enough that we had a small enough worry about a hostile fork. Maybe our fear of a hostile fork was overblown, unless you consider .NET to be a hostile fork of Java. I was talking with Ean Schuessler, Mark Weilaard and Dalibor Topic earlier today, and they reminded me of how the right to fork actually seems to result in fewer project forks in the first place. In practice OSS projects tend to realize it's better for everybody for the community to work in one project, rather than split up into multiple projects. The cost of maintaining a fork is pretty high.
In any case... hmm, for me the reason is that it leads us to ubiquity much more rapidly than any other method.
So, that's all the questions I can remember. If you have any questions there is a comment box below ...
Source:
weblogs.java.net
