"No more Java 7". Yes, I know its a strong statement, but I don't mean it in the way you probably think.
Update: I've followed up this blog with a whole series of articles:
* a description of how IP works in the JCP (pretty picture!)
* a deep dive into the behind-the-scenes world of the JCP to provide a clearer explanation of the lack of a Java SE 7 specification and how this affects the whole Java industry, not just Apache and Sun
* more info from the ASF board meeting minutes
* an exploration of how the JCP doesn't really exist
* a take on the Oracle-Sun deal
What is Java?
Well, the term 'Java' is a complex and overloaded one, including:
- the stock symbol of Sun Microsystems
- the trademark of Sun Microsystems
- the term for a raft of technologies based around the JVM
- a platform (Java SE) based around the Java programming language (
a programming language)
- the specification for the Java SE platform (
the specification for the programming language)
This blog post is about the last of these - the Java SE platform specification.
Back in 1997 Sun talked about making the Java programming language into a formal open standard. At that time, the ECMA was the standards body approached. However, Sun withdrew from the standards process and created the Java Community Process instead. Everyone breathed a little easier, as Java now appeared to be an effectively open standard.
The job of the JCP is to "... develop and revise the Java technology specifications, reference implementations, and test suites, the Java Community Process (JCP) program has fostered the evolution of the Java platform in cooperation with the international Java developer community."
Over the years, and with a few hiccups, the process hasn't gone too badly. There are multiple implementations of many of the JSRs, creating a healthy eco-system of competition and improvement. That is after all a key goal of any standard - to define what is necessary to produce a conforming implementation.
The JCP is, in fact, an unusual standards body in that it goes further than most to ensure that every specification must be tested before it is officially allowed to be released as an implementation of the specification. Each JSR (the individual standard) must provide an appropriate specification document, reference implementation and, crucially, a testing kit.
One group that has implemented many JSR specification is Apache. From Tomcat to Geronimo to JMS to the whole of Java EE. (And back in 2002, Apache had to fight to allow any Open Source implementations of JSR specifications.)
So, what has this to do with the end of Java SE 7? Well, as I said, I'm specifically referring to Java the specification. Now many people don't realise this, but as well as the JSRs for Servlets, EJBs and JMS, there are also JSRs for the whole of Java EE and for the whole of Java SE.
The relevant specifications are JSR-176 for Java SE 5 and JSR-270 for Java SE 6. These specifications are no different to any other JSR. The specification documents exist (mostly Javadoc). The testing kit exists. As does the reference implementation (the Sun JDK).
So, is it an open specification and open standard, as promised back in 1998?
Well, the Java SE specification has been implemented by other companies - IBM has a JDK amongst others. However, IBM pay money to Sun for the rights to do this. The question is whether Apache can implement it, just like they implement 25 other JSRs.
Apache's implementation of the Java SE 5 JSR specification is Apache Harmony. However, when Apache came to obtain the testing kit for the specification a whole political game started. Instead of Sun offering the testing kit as normal for each of the other 25 JSRs, they offered a testing kit where the results of the tested code would not be Open Source
Obviously, Apache couldn't accept this limitation, which is against the legal agreement signed between Sun and Apache. Apache complained 2 years ago, but has yet to receive an acceptable response. And no, there is no way a
charity not-for-profit like Apache is going to sue a multi-national corporation - who do you think would get the better lawyers?
The key point is that Sun's tactics here were quite deliberate. They knew exactly what they were doing by offering a testing kit with a restrictive license. They wanted to ensure that Apache Harmony couldn't be certified as complete. Sun was going out of its way to ensure that there was no competition to its own JDK.
In the meantime, Sun played the OpenJDK card. It announced the release of the JDK under the GPL license.
Lots in the community (notably those from a GPL background) suddenly became best friends with Sun. Some joined Sun, some now work closely with Sun. Many of these people now believe that there is no danger around Java, and that Richard Stallman's Java trap is over. I think this shows a gross lack of perspective - the code may now be GPL open source, but the specification is now no longer open. Which is more important?
If you can't freely implement a specification*, then I'd argue its not worth the paper its written on
* There are two ways you can implement the Java specification - (1) pay Sun money, or (2) ensure your code is "mostly derived from the OpenJDK".
What about Java SE 7? Everyone isn't noticing the obvious
I started with a contentious statement - that there may not be a Java SE 7 (open specification). So, lets look at the evidence.
To emphasise the point - JDK 7 is the implementation, Java SE 7 is the specification. But everyone at Sun is talking about the JDK (Open JDK), not the specification (Java) and this isn't an accident.
Project Jigsaw - Modularisation of the core of Java - No JSR planned. Funny, how such a major piece of infrastructure has managed to slide by without becoming an open specification...
To be fair, Mark Reinhold's recent blog is more positive - "The JDK 7 Project is creating a prototype of what might-or might not-wind up in the Java SE 7 Platform Specification. When the SE 7 Platform JSR is submitted then the features under development in JDK 7 will be proposed for inclusion therein, except for those that are VM-level or implementation-specific." (He uses the 'when the JSR is submitted phrase', but note the 'implementation-specific' phrase which conveniently covers Jigsaw at a minimum).
However, unless anyone is being particularly naive, it should be clear that if there is to be a Java SE 7 specification then it would be fully defined by what is in Open JDK, not by the JSR process. Do you think that Sun would remove things already in OpenJDK were the JCP to so decide? Er, no.
And look at the timeline. The full JDK contents are defined by September, yet there is no JSR for Java SE 7 yet. The first two milestones have already happened for goodness sake!!!
If the JSR happens it will be a rubber stamp. So why bother?
Next release - JDK 7, not Java 7
Yes, this is what I mean by the title of this blog. The evidence I see, and have shown here, is that the next release will be JDK 7, not Java 7. ie. there won't be an open specification.
Of course, since Sun own the Java trademark, Sun puts in all the investment and Sun has all the mindshare, the vast majority of developers won't notice this. In fact, since its now Open Source as the OpenJDK they might even think all is well. Sun's strategy to quosh all competition is working well isn't it?
What won't be realised is how 10 years of open standards have been lost. What won't be realised is how everyone is now locked into a new Java trap - a single vendor of anything that can truly be certified as Java. Its just a trap that Richard Stallman isn't interested in arguing against.
Personally, I would have thought that given all our experiences with the benefits of open Standards on the internet we would be demanding it of Java too - especially since it was promised back in 1997. We need to fight to retain Java as an open standard.
All the evidence I see is that Java SE is no longer an open standard and the next release will be JDK 7, not Java 7. That is something that should matter to all of us who care about the Java eco-system.
After all, if Sun can get away with making Java SE not an open standard, then why not Java EE, or Servlets or JMS? Its time to stand up and be counted and demand our open standard back!
Feel free to tell me why you think my analysis is wrong... I suspect you won't hold back...
For the record, I'm a member of the Apache Software Foundation, speaking personally here to point out something someone else really should have noticed...
Update 1: Please tag any follow up blogs or tweets with 'nojava7' so the feedback can be seen!
Update 2: For info, I've never contributed to either Apache Harmony or the Open JDK, although I have used the OpenJDK in Kijaro and work on JSR-310. As such, I'm pretty dispassionate about the quality or usefulness of Harmony/OpenJDK. I care more about the lack of an open specification for Java 7, which is what this blog is primarily about.
Update 3: I haven't seen any evidence that the engineering team at Sun don't want a Java SE specification. The evidence I see is that this is driven from a higher business/management level.
Update 4: I've clarified the initial 'meanings of Java' section to place the emphasis on the Java Platform, as explained here. (The licensing terms are well worth a read - particularly number 7)
Update 5: I've updated Java 7 to Java SE 7 in a few places to aid clarity. Most people probably understand that Java EE and Java ME are different, but it helped in a couple of places to be extra sure.
Update 6: Fixed "offering Sun the testing kit" to "Sun offering the testing kit"