Shedding new light on No Java SE 7 JSR

There is a direct connection between the 'Sun vs Apache Harmony' dispute and the lack of a Java SE 7 platform JSR. Using newly available evidence I hope to shed new light on what that link is.

Back in the day

Its interesting to read again how Harmony was welcomed when it first started:

Part of the reason these Apache projects are possible is that the JCP has been working over the last few years to clarify the role of open source projects and also to improve overall transparency. For example there were changes to the intellectual property rules in JCP 2.5 specifically designed to allow open source implementations. There have also been a number of transparency improvements in JCP 2.6 to allow earlier access to specification information. In addition to those JCP updates, Sun created a scholarship program under which we have provided Apache (and other not-for-profit groups) with free access and free support for Sun's Java compatibility test suites.
...
The licensing rules for J2SE 5.0 were carefully designed to allow independent, compatible open-source implementations of the J2SE specification. Personally, I am not entirely sure if the world really needs a second J2SE implementation, but at the same time I am also glad to see that all the effort we put into getting the rules and the licensing issues straightened out is actually proving useful!
Graham Hamilton's blog VP and Fellow at Sun responsible for Java at the time, written May 7, 2005.
(My emphasis)

And lets look at how that was reiterated in the business terms for Java SE 6:

JSR 270: JavaTM SE 6 Release Contents
...
2006.10.24:
2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.
...
7. Nothing in the licensing terms will prevent open source projects from creating and distributing their own compatible open source implementations of Java SE 6, using standard open source licenses. (Yes, you can create your own open source implementation of Java SE 6 if you really want to. But we're also doing everything we can to make it easy for you to use the original RI sources! See http://jdk6.dev.java.net.)

JSR-270
(My emphasis)

How times change. Update: The 'how times change' reference was a comparison of both of the above quotes to the dispute that followed, not a comparison of the two quotes. Sorry for the confusion.

Trying to resolve the dispute

As is clear, Apache claim that Sun is in violation of the JSPA contract for both Java SE 5 and Java SE 6 platform specifications. The comments above also indicate how matters changed over the course of time.

Given the dispute, it is clear that Apache would object to there being a Java SE 7 platform JSR without changes being made to resolve the issue. However, Apache is just one voice in the industry. The power in the JCP is held in two 16 member Executive Committes - one for Java SE/EE and one for Java ME. Clearly, therefore, Apache could be outvoted 15-1 on the SE/EE committee, and it has no vote on the ME committee.

So, why hasn't Sun just submitted the Java SE 7 platform JSR and accepted/ignored Apache's No vote?

Well, until recently, I thought that the reasons were all private information. However, it turns out that since September 2008, the Executive Committee meeting minutes have been openly published. As such, we can see how the Executive Committees have tried to resolve the issue. As far as I know, no journalist or blog has yet picked up on this.

Given the controversial nature of this, I strongly encourage anyone following this to read the minutes themselves. Its a good insight into the the way in which the JCP operates (a style probably typical of any commercial based standards body). In this section I will extract some key elements, and make some minimal comment, but please read the full documents to make up your own mind.

Meeting summary - February 27th 2007
Geir Magnusson presented on a hypothetical situation regarding a company pursuing a certain Java-related business opportunity and whether the JSPA allows licenses that could affect that opportunity. During the meeting Geir asked for a straw poll on the following statement:
"The Executive Committee of the JCP supports the Apache Software Foundation's assertion that placing limitations on field of use for compatible implementations of Java specifications is contrary to the letter of the JSPA and the spirit of the JCP as a creator of open specifications."
Voting "yes": 17
Voting "no": 2
Voting "abstain": 3

(Geir Magnusson is the Apache representative on the Executive Committee)
(Note that the official document status is draft and unapproved, however it is publicly linked from the JCP website)

Note the 'straw poll' explicitly mentions the field of use restriction that Sun used against Harmony. This vote represents the collective wisdom of the two Executive Committees - Java ME and Java SE/EE - 32 votes in total, however there were 10 absentees.

Note that there were two 'no' votes.
Also note that Sun sits on both executive committees and thus has two votes.
But there is no other information to tie those two facts together.

Meeting summary - December 7th 2007
Resolution 1 (proposed by Oracle, seconded by BEA)
"It is the sense of the Executive Committee that the JCP become an open independent vendor-neutral Standards Organization where all members participate on a level playing field with the following characteristics:
* members fund development and management expenses
* a legal entity with by-laws, governing body, membership, etc.
* a new, simplified IPR Policy that permits the broadest number of implementations
* stringent compatibility requirements
* dedicated to promoting the Java programming model
Furthermore, the EC shall put a plan in place to make such transition as soon as practical with minimal disruption to the Java Community."

Vote tally from SE/EE Executive Committee:
Voting "yes": 13 (Apache, BEA, Fujitsu, Google, HP, IBM, Intel, Doug Lea, Nortel, Oracle, Red Hat, SAP, Hani Suleiman)
Voting "abstain": 1 (Sun)
Vote tally from ME Executive Committee:
Voting "yes": 13 (BenQ, Jean-Marie Dautelle, Ericsson, IBM, Intel, Nokia, Orange, RIM, Samsung, Siemens, Sony-Ericsson, Time Warner, Vodafone)
Voting "abstain": 1 (Sun)

Note how the proposal is explicit about the JCP becoming 'independent' and 'vendor-neutral'. Note also how the proposal accepts that the costs of such a body would have to be shared by its members. Again, the two Executive Committees - Java ME and Java SE/EE - clearly voted in favour of a resolution to further open the JCP. The sole exception was Sun, who abstained.

Meeting summary - December 7th 2007
Resolution 2 (proposed by BEA, seconded by Intel)
"The SEEE EC requests Sun to submit a Java SE7 JSR with the following characteristics:
* EG members will share costs by contributing to the TCK and RI submitted under common licensing terms that will allow any implementer to use them;
* accompanied by public spec, tck, ri licenses at JSR initiation;
* licenses do not contain Field of Use restrictions on spec implementations.
* the JSR is operated by the Spec Lead under democratic principles (e.g. Java SE6)
Furthermore, from the time of submission, TCK license(s) for Java SE5 and later will be offered without field of use restrictions on spec implementations enabling the TCK to be used by organizations including Apache."

Vote tally from SE/EE Executive Committee:
Voting "yes": 10 (Apache, BEA, Fujitsu, Google, Intel, Doug Lea, Nortel, Oracle, SAP, Hani Suleiman)
Voting "abstain": 4 (Sun, HP, IBM, Red Hat)

So, the SE/EE Executive Committee clearly voted in favour (10-4) of a resolution in favour of an open Java SE 7 specification, and for Apache to receive the testing kit for Java SE 5 and 6. There is no information available as to the details of the discussion, nor or the reasons why individual participants voted for or against.

Meeting summary - April 8th 2008
Sun's commitments on JCP reform
Onno Kluyt gave a presentation in which he outlined a series of JCP reforms that Sun is willing to commit to. The presentation was followed by an extensive discussion.
Java SE 7 JSR
Roberto Chinnici summarized Sun's plans for the Java SE 7 JSR, expressing the hope that this would be submitted and approved soon.

We can note that back in April 2008 Sun were making efforts to resolve the issues. Also note that Sun expressed the desire to submit the Java SE 7 JSR 'soon'. I'd also note that April 2008 is just before JavaOne 2008, which was in May - a time when Sun frequently makes big announcements.

Meeting summary - June 24th 2008
Geir Magnusson and Onno Kluyt reported that Sun and Apache have failed to reach agreement on the terms under which the JCK would be licensed to Apache for use in the Harmony project. They also reported that no further discussions are planned. Onno stated that Sun has no immediate plans to submit the JSR for Java SE 7. Rather, Sun plans to continue SE 7 development work through the OpenJDK project and through component JSRs that are already in progress. He expressed the hope that when the JSR is submitted at some point in the future the EC will approve it.

EC members expressed their disappointment at this outcome, and discussed the possible implications without reaching any firm conclusions.

Sun now have 'no immediate plans' to submit the Java SE 7 platform JSR. It is fair to ask what happened between April and June to cause the submission of the JSR to go from 'soon' to 'no immediate plans'. Sadly, there is no published information to answer that question, so I'll leave that open to debate (I can't comment further).

Further, it can be seen that Sun are beginning to focus on working towards version 7 using Open JDK instead.

Meeting minutes - September 25th 2008
Patrick gave an update on the upcoming elections, and informed the ECs of Sun's nominations:
...
Several members expressed concern that they weren't consulted about Sun's nominations. Patrick said that Sun was unwilling to make concessions on "control points" (such as the right to nominate for EC elections) without something in return. When members asked what concessions Sun wanted, Patrick responded that Sun expressed the desire to feel confident that the Java SE7 JSR would be considered by EC members without allowing the dispute about TCK licensing between Apache and Sun to obstruct it.

This passage shows Sun as being concerned about whether the Java SE 7 JSR would be considered without the TCK dispute being resolved. Further, they link certain aspects of Sun control in the JCP (ie. who gets a guaranteed seat on the JCP) to the Java SE 7 debate. I'm not going to speculate on the details of what is clearly a politically-charged passage.

Meeting minutes - September 25th 2008
Private Session
The ECs then went into private session for a discussion on the negotiations between Apache and Sun.
After these discussions it was agreed that Apache and Sun would explore the possibility of arbitration to resolve their differences.

Arbitration is mentioned as one possible solution.

Compatibility Rules discussed at the meeting on September 25th 2008
Slide 13:
Compatibility is a contractual obligation.
- You must not ship incompatible products.
-- Compatibility is binary.
- You can't be "almost compatible" or "a little bit incompatible".
- The JCK contains 120,000 test cases.
-- If you pass 119,999 you are not compatible.
-- If you pass 120,000 and don't meet all the other requirements you are not compatible.

This hammers home the point that any implementation of any JSR must be fully compatible. And that it is a contractual obligation. It also shows the size of the Java SE platform JSR testing kit.

Meeting minutes - January 13th 2009
Private session
The ECs then went into private session to discuss the status of the Sun-Apache negotations. During this session members had a lively discussion, and made some proposals that will be brought to the attention of Sun's management

Again, discussions to resolve the issue by the Executive Committee are still ongoing in January 2009.

There are no further minutes publicly available - January 2009 is the last published date. However, the next meeting is on April 9th 2009, so we should expect to see the minutes from February 25th approved at the April meeting very soon.

Any clearer?

I hope that these quotes, and the original minutes, provide a deeper insight into the dispute, and into how the Java SE 7 is affected. I'll draw out three points:

Firstly, that this isn't just Apache vs Sun. Other members of the Executive Committee have been willing to side with Apache and vote against Sun (February and December 2007). Bear in mind that those members have access to even more information than is public here in order to judge which way to vote. Remember though that those votes are not-binding. Due to the structure of the JCP, the other Executive Committee members cannot actually intercede on behalf of Apache.

Secondly, from the September 2008 meeting, there is distinct evidence (but not proof) that Sun feels unable to get a Java SE 7 JSR passed until the Harmony dispute is resolved. We can also note the difference in tone between April 2008 and June 2008, where a Java SE 7 platform JSR went from 'soon' to 'no immediate plans', and Sun's focus became clearer around using Open JDK instead of a JSR.

Finally, it is clear that discussions have continued in one form or another for the entire time of the dispute. It isn't the case that the Apache open letter was published and then forgotten or ignored.

Despite all the efforts, there has been no solution. And as such there is still no Java SE 7 platform specification. Thus, I hope its a little clearer why I'm arguing that, in all likelihood, we will get a JDK 7 implementation, but not a Java SE 7 platform open specification.

Summary

Personally, I'm glad these meeting minutes are now public. Everyone can now see the behind-the-scenes discussion for themselves and make up their own minds as to the true state of the debate. In addition, you can freely judge if my blogging has been factual or not.

Finally, for anyone still wondering why Apache Harmony might be of any value at all, consider this:

Apache Harmony: Thanks for the TreeMap Work!
I'd like to thank Apache Harmony for their JDK library performance efforts. We were given a tip that the Harmony folks were doing some interesting work with the TreeMap collection class, and low and behold they were.
...
Controlled measurements showed the "fat" TreeMap significantly faster with in order traversals, and improved our SPECjbb2005 score by a solid 3-5% depending on the platform.
...
Considering the potential performance gain we started the effort of porting the Apache Harmony TreeMap code to JDK 6.
...
The new TreeMap is included in JDK 6 Update 6 Performance Release
David Dagastine

So, Sun's JDK runs faster today as a direct result of code written in Apache Harmony. If you use Sun's JDK 6 update 6 or later, Apache Harmony has already benefited you. And that just one of the benefits of open specifications and competing implementations.

Stephen Colebourne
Apache Software Foundation member, speaking personally
Sun Java Champion, speaking personally
Not a committer on Harmony or OpenJDK

Sun, Apache & IP - in pictures!

This blog explains the JCP IP process in pictures. And how Sun have managed to use it to block Apache Harmony.

IP in the JCP - how it should work

Within the expert group, a number of experts make contributions. Each member agrees, as part of the JSPA agreement, to grant their IP to the spec Lead. The spec lead will also add IP in the same way. This produces a 'pot' of collective IP owned by the spec lead on behalf of the expert group.

The expert group produces two outputs in addition to the IP - the specification itself and the testing kit.

An implementor of the specification uses the specification document (which may well include Javadocs) to develop the implementation. The implementor will probably have their own unit tests at this stage.

When the implementor feels that the development is nearly complete, they request the testing kit (TCK) from the spec lead. They then use that to test the implementation (and fix any bugs).

Once the testing kit has been passed, there is another stage that isn't found in a typical project. This is the stage of 'obtaining the collective IP' from the spec lead. This should be automatic if the testing kit is passed and the implementation is complete and valid.

Finally, the implementation can be released. It can now claim to be a compatible implementation of the JSR. And the collective IP has been granted to avoid any unpleasant surprises down the road for users.

What about Apache Harmony?

Well, its important to realise that Sun didn't expect that Harmony would succeed. They thought that the task was too big. As such, they assumed that they would never need to worry about providing a Java SE testing kit, even though they'd agreed to do so.

Instead of keeping to the agreement they had signed, Sun used its lawyers to come up with a cunning way of blocking Harmony:

What Sun did was add a 'Field of Use' clause (FOU) to the license for the testing kit. This clause infected the tested code, and thereby infected the release.

The precise details of the FOU are confidential at the behest of Sun, however in summary they state (rather absurdly) that the tested code cannot be run on a PC in an enclosed environment. Thus, you could run a tested version of Harmony on your PC providing it is running on your desktop. But if you pick the machine up and place it in an enclosed cabinet, such as inside an X-Ray machine, or an shopping mall information kiosk, then you would be breaking the FOU clause.

Sounds absurd? Well it is yes.

But remember, Sun didn't need something sensible. They just needed something, anything, to stop Harmony.

By adding this clause, it meant that the tested code would need to contain an additional clause over and above the standard Apache license. A clause that would be invalid for any open source software as defined by the OSI. To be clear, this FOU clause would be an issue for any open source group trying to implement the Java SE specification.

Since Apache only releases open source licensed code, Sun could therefore effectively block the release of Harmony. And in the meantime, it could spend all its efforts fooling everyone that Java is an open standard using the Open JDK initiative - an open implementation, not an open standard.

Summary

Sometimes a picture tells the story clearer than text. Hopefully, these pictures will help illuminate you. If not, you can always read the legal agreement.

A question of IP

My post about the lack of an open specification for Java SE 7 raised some eyebrows yesterday. One point I wanted to clarify in a little more detail is how the JCP treats IP.

Warning! I am not a lawyer. This is written to the best of my knowledge, but I may well have something messed up. Feel free to tell me I'm wrong, but please provide a link explaining why!

The JCP and IP

IP (Intellectual Property) is one of the aspects which any good specification needs to define. For example, here are the relevant terms for the W3C. Put simply, the IP, and associated, restrictions describe what rights you are granted.

For the JCP (Java Community Process), the relevant document is the JSPA. I'm going to try and outline some key sections here.

4. Intellectual Property; In-Bound.
A. Contributions to the Spec Lead. You hereby grant to each Spec Lead ... with respect to the Output of the JSR ... a perpetual, non-exclusive, worldwide, royalty-free, fully paid-up ... irrevocable, license, with the right to sublicense:
- Copyrights and Trade Secrets ....
- Patents ....
B. Grants to Other Expert Group Members. You hereby grant to Member represented on any Expert Group ... Your applicable patents, copyrights and trade secret rights which You currently have or may acquire in the future a perpetual, non-exclusive, worldwide, royalty free, fully paid-up, irrevocable license to use Your Contributions for research and development purposes related to the activities of such Expert Group. Similarly, Sun makes the same grant to You with respect to its Contributions concerning Expert Groups on which You are represented. These grants, from You to other Members and from Sun to You, shall not include distribution to third parties of early access implementations of the Spec under development by Your Expert Group until the draft Spec has been released for Public Review.
C. Contributions from Sun and Ex-Spec Leads. For Contributions from Sun under JSRs for which You are the Spec Lead, Sun hereby grants to You the same license with respect to Sun’s Contributions ...

This refers to expert group members contributing to the JSR. I've snipped quite a bit to avoid too much legality. The key elements are:

• the members of each JSR license their IP (copyrights, trade secrets, patents) primarily to the spec lead
• the same grant is also made to other JSR expert group members, for R&D prior to the JSR being finalised
• the granted rights cannot be used publicly until the JSR is in public review
• Sun grants the same

One thing to note is that Sun's participation is explicit in the JSPA. Sun is not "just another participant" in the JCP - it has special rights.

The next section is an interesting revoke section:

D. Withdrawal of Contributions due to Change in Announced License Terms. If the Spec Lead for an Expert Group in which You are participating makes significant changes to the terms and conditions of any license granted pursuant to Sections 5.B or 5.F below after those terms and conditions are first disclosed pursuant to the Process, then You may, upon giving notice to the Specification Lead and the PMO, withdraw any copyright or patent licenses concerning Your Contributions granted pursuant to Section 4.A.I or 4.A.II above (but not patent licenses granted by You pursuant to Section 6 below).

Put simply, if any spec lead breaks the license terms that they have already agreed to, then the granted IP from other expert group members can be revoked.

The next section is about what happens when the spec is published:

Intellectual Property; Out-Bound.
A. Ownership; Obligation to Publish Spec.
... the Spec Lead(s) for a particular JSR at the time of the final release of the Specification shall own the copyright to the final Spec generated pursuant to that JSR under United States copyright law. Promptly after its completion ... such Spec will be published by the PMO at the JCP Web Site.

For example, for the Java SE specs, Sun owns the copyright, as it is the spec lead.

B. License to Create Independent Implementations.
... the Spec Lead for such JSR shall offer to grant a perpetual, non-exclusive, worldwide, fully paid-up, royalty free, irrevocable license under its licensable copyrights in and patent claims covering the Specification (including rights licensed to the Spec Lead pursuant to Section 4.A and 4.C) to anyone who wishes to create and/or distribute an Independent Implementation of the Spec. Such license will authorize the creation and distribution of Independent Implementations provided such Independent Implementations:
(a) fully implement the Spec(s) including all its required interfaces and functionality;
(b) do not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields or methods within the Licensor Name Space other than those required/authorized by the Spec or Specs being implemented; and
(c) pass the TCK for such Spec.
...

Here is the key part! The spec lead grants the IP to everyone that implements the spec. But only if they meet the three criteria.

• the implementation must fully implement the spec
• the implementation must not modify the spec
• the implementation must pass the testing kit

So, everyone grants their IP to the spec lead. And then the spec lead grants that IP to the implementor once the three conditions are met. Of course, to meet the three conditions, you have to have access to the testing kit...

Since Apache Harmony is prevented from passing the Java SE specification testing kit, it cannot meet the three criteria. Since it cannot meet the three criteria, it cannot receive the IP grants of copyrights, trade secrets and patents.

And as a not-for-profit, there is no way for Apache to take any legal risks. It certainly can't just assume that there is no IP to be granted (there almost certainly is).

A section on licensing of the testing kit:

F. Licensing of RI and TCK.
I. The Spec Lead (including Sun) for a JSR approved by the JCP shall offer to any interested party licenses concerning the RI and TCK -- and also the TCK separately when developed under any JSR submitted hereafter -- on terms and conditions that are non-discriminatory, fair and reasonable. Except as otherwise set forth in this Section 5.F, such terms and conditions shall be determined by the Spec Lead in its reasonable discretion.

So, the testing kit (TCK) has to be licensed in a "non-discriminatory, fair and reasonable" manner.

III. With respect to the TCK when licensed separately from the RI, for a Qualified Not-for- Profit or Qualified Individual there shall be no charge for the license offered by the Spec Lead.

The JSPA is clear that "Qualified Not-for-Profit" groups, like Apache, are fully entitled to the testing kit free of charge. Sun haven't disputed that.

V. No provision of this Section 5.F shall be understood to require that the Spec Lead license the RI (or TCK) in source code form...

The JSPA is clear that the testing kit does not need to be open source, or even source code available. Thats not in question by Apache or Sun.

Finally, a section on trademarks:

8. Use of Trademarks. Subject to any other rights and obligations ... You may refer to Sun's Java technology or programming language to the same extent as the general public, provided that such reference is not misleading or likely to cause confusion....

Thus, the JSPA grants no special privileges with respect to trademarks. Apache and Sun agree on this. Apache isn't seeking to use the Java trademark.

Another (simpler) summary is the original Apache FAQ on the JSPA and associated issues. Take a read if you're still confused.

Summary

All legal agreements are complex, and this is no exception. But the principle is simple.

Each Expert Group member licenses their IP (copyrights, trade secrets and patents) to the spec lead. The spec lead then licenses that 'collective IP' to anyone that successfully implements the specification.

In the case of Apache Harmony, because Sun is preventing Apache from receiving the testing kit under an appropriate license (see the Apache FAQ), it is impossible for Apache to verify that the Java SE specification has been met. As such, Sun cannot and will not provide the required IP grant to Apache, and thus Apache cannot release Harmony.

As I said yesterday, for Java 7, the easy solution for Sun may well be to simply not have an open Java SE 7 specification.

No more Java 7

"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.

Blogs, blogs and more blogs - Every blog from a key Sun employee in recent times has referred to JDK 7, not Java 7. Read them carefully!!! Still think there is guaranteed to be a Java 7?

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.

Summary

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"

Speaking on Fantom tonight in London

Quick note to say I'm speaking on the Fan Fantom programming language tonight in London. The evening will also include a brief intro to OSGi.

Its at the JavaWUG user group, hosted by Skills Matter, registration required to attend.