jcp Archives - Community Over Code

The JCP is dead; long live Java

The Apache Software Foundation has just announced it’s resignation from the Java SE/EE Executive Committee. After several other recent community departures from the EC, and scathing commentary supplied as comments with the votes from other EC members for the recent Java 7/8, it’s clear that Apache is not alone in it’s dissatisfaction with Oracle’s complete and overt control over what is purportedly a community effort. As another Apache member has said:

The Executive Committee is clearly not a Committee of Executives, nor is the Java Community Process a Process involving the Java Community.

I applaud everyone who has done technical work on recent versions of Java, and I’m sure plenty of people will still want to program in Java. That’s great. But please – when you do use Java, please remember that it is *not* built on open standards. It is built on technology (and patents) and licenses that Oracle controls, and is quite happy to exercise it’s control over all things Java.

If you’re happy paying Oracle more and more licensing fees in the future, more power to you. But if you’re not, then you really need to understand the problem of the TCK Trap.

Stay tuned for more updates from the ASF’s Foundation blog on what this means for the many many excellent Java based Apache projects. And, follow the #jcpisdead hashtag to understand what impact it may have on your Java future.

For more reading, follow my set of ‘oraclemess’ Delicious bookmarks.

Java: no longer free as in speech

El Reg has breaking news that the JCP vote on the Java 7/8 JSR’s has passed. Apache and Google voted no, and the rest of the players sadly (but perhaps unsurprisingly) voted yes. This effectively changes the game around Java standards stewardship – you might say it turns the JCP into “Just Customers, Please“, removing any real community input that Oracle doesn’t choose to accept.

There are plenty of past links to learn about what this really means, and I’m sure that Stephen Colebourne will have some insightful commentary once he wakes up and has a cup of jav… er, tea.

A key indicator of the feeling of the JCP are the signing statements that most of the “Yes” voters supplied: all (except Oracle) agreed with Apache and Google that the FOU restrictions Oracle is mandating are objectionable and inappropriate (not to mention apparently incompatible with the JSPA). If only wishes were horses, and signing statements had real force, then we could all be happy.

I’m not that surprised that the larger software vendors cast their votes where they think their bottom lines are, and went with a “Yes”, FOU reservations in their signing statements notwithstanding. I am a little surprised that Eclipse and Red Hat caved into Oracle, given that their businesses are also open source, and they’re clearly going to have to pony up to Oracle somehow to get sufficient licenses to continue shipping Java related software.

Don’t get me wrong: for all the Java developers who don’t care about how their underlying technology is licensed, I’m happy for you! You now have Oracle’s Java roadmap, and presumably Oracle will start delivering some cool Java technology. But please: don’t fool yourself or your friends into believing that the Java standards ecosystem is open, free, or community based in any real way. Oracle owns the court now, and don’t be surprised if it starts charging some people for renting balls along with court time to play.

It’s a sad day, since I really do like programming in Java. I still will, sometimes; but not as often. And not without realizing that Java is no longer free as in speech. We’ll see how long that Java remains free as in beer, now that Oracle’s realized they run the JCP.

OpenJDK += Oracle, IBM

The big news this week is the sudden move by IBM to join with Oracle in collaborating on the OpenJDK. You can read the formal joint press release, or browse some of the first set of thoughtful commentaries here:

IBM’s Bob Sutor talks about the IBM decision to move into OpenJDK – at the expense of contributions to Apache Harmony. Bob also has another good roundup of news coverage of this story.
InfoQ asks some good questions about IBM’s and Oracle’s plans around this move.
Paul Querna’s take on the Java Trap is a good perspective from a long-time open source contributor.
Sacha Labourey’s “pragmatic” take on the blow this deals to community around Java.
Gary Barnett’s posting seems to say this is good news, although he’s really understating the “serious concerns surrounding the JCP”.
Steve covers The new cold war: IBM and Oracle against Google.
Tim Ellison’s (unfortunately brief) post on the subject. I include this since Tim is the current VP of Apache Harmony.
And although it’s a week old, James Governor’s post on Java: The Unipolar Moment is well worth a read for a detailed analysts view on the ecosystem before this announcement.

Required reading: everyone should re-read the ASF’s open letter to Sun Microsystems about the JCP. If you don’t remember why that letter is important, then go back through the Graphical Overview of Sun’s JSPA violations. If you like using the word “open” anywhere near the word “Java”, then you need to remember that they don’t really go together these days.

Graphical overview of Sun’s JSPA violations

Stephen Colebourne has done an amazing job in explaining Sun’s violations of the JSPA and why it’s important to the ASF and open software. This is a must read for anyone interested in the issue of shipping open or free Java software.

There’s a lot of commentary – both pro and con – over the ASF’s open letter to Sun about the JSPA and Sun’s inappropriate field of use restrictions on the JCK that would be provided for Apache Harmony. It seems that much of the commentary is missing the true issues, either from not understanding the true the details, or because people or organizations have their own agendas to promote.

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. – S. Colebourne

Here are some resources that are worth reading about the issue:

Stephen’s excellent graphical overview
: This shows clear pictures of how Sun inserts a field of use restriction clause to block Apache Harmony.
Stephen’s overview of IP throughout the JCP process: This shows how the JCP is supposed to safeguard and provide open licensing of IP within any specification, ensuring that independent vendors can implement the specifications.
The ASF’s Open Letter to Sun: This is the official position of the ASF, and while it’s an important document, it’s not as easy to read as other sources. There is a FAQ from the ASF available which offers some insight.
Geir’s commentary on the current state of the issue: The ASF’s own Geir Magnusson Jr., VP of JCP, and Dalibor Topic duel over the topic, alternately attempting to sidestep the issue or lock horns straight on.
The actual JCP vote on JSP-316: Java EE 6: While the ASF is the only organization that actually voted No, you really need to read the comments from other voters, as well as evaluate the Abstain votes.
The JCP’s own procedure documentation, including a glossary: The JCP itself has governance rules. If you really want to understand the background about how the JCP works, there’s a lot more history; in this case it’s really the foundation of how JCP rules that is at issue with what Sun has been doing.