What about JSR-310?

So, if the Java Community Process is now a zombie Java Corporate Partnership, what should I do with JSR-310?

JSR-310

I've been highly critical of Oracle's stewardship of Java, particularly on the topic of the JCP. Choosing to U-turn on their previous public statements and force through the Java SE 7 and 8 JSRs was bad for Java and bad for Oracle. By accepting Oracle's actions, the remaining JCP executive committee members ended the notion of the JCP as an open standards body.

So, the question arises as to whether I should cut my ties with the JCP and terminate JSR-310.

The reasons to abandon the JSR are quite compelling:

• The JCP is no longer an open standards body.
• JSRs now exist that are in incompatible with the JSPA legal agreement.
• The Executive Committee has shown itself to be more willing to do Oracle's bidding than to hold them to account.

However, I must also ask what the result would be if I stopped the JSR:

• I would break a commitment I made to the community to improve dates and times in Jave SE.
• Someone else might take over the project, perhaps causing another poor Java SE date and time library.
• The majority of developers, those that don't read blogs and news sites, don't care about the corporate politics and would suffer without ever knowing why.

Ever been between a rock and a hard place?

The upside is that the process of the JCP provides all the power to the specification lead. So, since I, and Michael Nascimento, are the specification leads for JSR-310, we have all the power :-) Consider what I said when the JCP asked me about transparency:

Anyone can access these javadoc files by just clicking a link on the JSR 310 website at java.net. Stephen says, "We always intended to run the JSR as an open source project. That naturally means public code, and feedback. Collecting the feedback is easier if people can access it by the method they are most familiar with -- javadoc." Some Spec Leads may be reluctant to run their projects as openly as this, but Stephen has no qualms at all. He says, "It's often thought that being open will increase the mails and issues you have to deal with. The reality is that you tend to have to address the real issues earlier than you might otherwise have to, and that is a very good thing."

The key phrase is "run the JSR as an open source project". Because if the JSR is an open source project then the status of the JCP is more of a detail, an annoyance.

So, while my heart might tell me to walk away from the zombie JCP, my head tells me that I really don't need to. This is just an open source project which the community badly needs. And the JCP is just a tool I can use to access Java SE 8. I dislike maven as a tool, yet I still use it - I can dislike the JCP and still use it in exactly the same way.

Therefore, I've decided to continue work on JSR-310, targetting Java SE 8.

I've also taken advantage of the impending destruction of the original java.net website to move the code and discussion to sourceforge, where I hold most of my other projects.

I've also chosen to give the reference implementation a real name - ThreeTen. So, the ThreeTen project is the reference implementation of JSR-310. Development of both the reference implementation and the JSR will occur at the ThreeTen project.

• ThreeTen home page
• ThreeTen project page
• Develop mailing list

As part of this process I've attempted to clarify the legal position of contributions to the project, including discussion, without getting too legal. The concept is that the overriding principle is that the project works on trust and respect for the public good. Beyond that, version controlled contributions continue to use the BSD 3-clause license, and version controlled contributions destined for JSR-310 continue to require a contributor agreement. As such, existing mailing list subscribers need to resubscribe to the new mailing list.

I also leave open the option of writing a ThreeTen specification separate to the JSR-310 specification.

The aim of a ThreeTen specification would be to provide common terminology and behaviour at a higher level with the intention of sharing the knowledge gained to other areas of computing. This might be another language, library or specification, such as SQL or XML.

Finally, I'm pleased to confirm that I will continue to spend 20% of my work hours on ThreeTen/JSR-310 thanks to my employer OpenGamma where the project is a core part of their platform for financial analytics and risk management.

Stephen Colebourne
Project lead, ThreeTen
Co-spec lead, JSR-310

The Deal

This is the story of a deal. Not one that was ever signed on a piece of paper. But one that was still very important. Its the deal between the owner of Java and the Community.

The Deal

This is my view about how the owner of Java and the Community have interacted:

The owner of Java makes a large investment.
The community makes it relevant.

By "owner of Java", I mean Sun, then Oracle.
By large investment, I mean money, development time, marketing and energy.
By relevant, I mean interesting and productive for mass use.

The key point is that this is a symbiotic relationship. The investment by the owner is worth much, much less if the language is not relevant. And the community needs an actively developed core and common set of rules to build upon.

When you consider the limited nature of the core of Java, this should be self evident. The core consists of the JVM, compiler, language and core libraries. Enough to get everyone started, but not that interesting in and of itself.

What is interesting about "Java" is everything else:

Servlets, JMS, Tomcat, JBoss, Lucene, JMX, Eclipse, Ant, Portlets, Lombok, Devoxx, Javalobby, Axis, JIRA, RESTEasy, Terracotta, Ivy, JSP, TestNG, Grails, Mule, Android, ICU4J, MyFaces, Scala, James, Geronimo, JCS, OFBiz, Jetty, GWT, Websphere, JFreeChart, JavaMail, FastUtil, Xerces, JDBC, Griffon, JProbe, SLF4J, Wicket, XOM, JavaOne, Seam, Emma, HttpClient, EHCache, TheServerSide, Roo, Mockito, HSQL, Guice, FOP, Kindle, Velocity, Clojure, JNDI, Clover, Hadoop, JSF, Jackrabbit, Livescribe pen, Commons, Hibernate, EJB, Tobago, IntelliJ, Jersey, Scalaz, HornetQ, JAX-RS, Lift, Derby, JUnit, Freemarker, JavaME, Mylyn, Gaelyk, MINA, Play, JBPM, Cobertura, Antlr, Artima, Findbugs, Hessian, OGNL, Quartz, Trove, Tales, Javolution, Weblogic, Spring, Maven, QCon, Guava, JPA, Colt, Zing, Pico, JAXB, Applets, Struts, Groovy, JavaFX, Log4J, BluRay, Glassfish, Tapestry, JavaRanch, JRoller, Fusion, Excelsior JET, JAX-WS, BIRT, JDOM, Yourkit, SmartCard, JTA, Fantom, Gradle, Netbeans, OSGi, CXF, JSTL, ActiveMQ, JEDI, Camel, JRuby, ServiceMix, Jython, Joda-Time, and many, many more!

It is a huge ecosystem - with a gigantic community

The investment by Sun, now Oracle, is miniscule compared to that of the rest of the community. Essential and vital, but miniscule.

And that is The Deal! The investment by Sun/Oracle (which is increasing under Oracle) is a whole lot less valuable if the community and ecosystem is destroyed. And that is why the recent Java Community Process debates really matter.

In order to function, there needs to be a safe base for everyone to work off. This has for many years been investment from Sun/Oracle moderated via the Java Community Process. But that deal has hit a major roadblock in the last few months.

The crazy part is that by damaging the community, Oracle's actions damage themselves! As The Deal indicates, Oracle's current increased investment, and the pushing forward of Java 7 and 8, is of limited value if the community and ecosystem ebbs away and ceases to make the platform relevant.

The lawsuits and JCP actions simply serve to push that community away, creating distrust. Some in the Oracle management chain need to think again about what community and ecosystem really means.

Sometimes it means taking decisions that are against the immediate and obvious business benefit in order to keep the community and ecosystem happy and productive, gaining a bigger business benefit later.

The message is simple. Everyone in the community and ecosystem, from the biggest company to the smallest individual matters. Even those who might be classified as "enemies" or "competition" are in fact business partners who are vital to Oracle's investment in Java.

That's what a symbiotic relationship means. And what The Deal summarises.

Stephen Colebourne
Personal opinion about the state of the Java community

Is the JCP dead?

Today, the Apache Software Foundation (ASF) joined Doug Lea and Tim Peierls in resigning from the Java Community Process (JCP) Executive Committee (EC). The message from the ASF was simple - The JCP is Dead. But is it?

Is the JCP dead?

The JCP, is the Java Community Process, setup in 1998. But why did it get created at all?

Well, back in 1996 - 14 years ago - Sun started on the road of creating an globally recognised Open Standard for Java at the International Standards Organisation (ISO). This standard was a promise to the community, in part to gain adoption of the platform.

If you weren't involved in Java at the time this might seem unimportant. Yet I can remember using the promise of an Open Standard as one of the arguments for adopting Java as the principal language in the insurer I worked at. I'm sure other developer's similarly found the Open Standard argument useful in adoption discussions. That promise was responsible in part for the rapid adoption of Java.

Sadly, the tale of standardisation through ISO, and then ECMA, is a sordid one. This was a time when Microsoft feared and abused Java resulting in a lawsuit. Sun faced two main hurdles. Firstly, that it wouldn't give up its copyright, patents, trademarks or rights to the compatibility testing suite (which ISO wanted them to). And secondly, the very rational fear that its competitors, notably Microsoft and HP, would abuse the standards process to gain control of, and destroy, Java. (For full details, see this excellent academic paper).

The JCP was setup effectively after the efforts at ISO and before the efforts at ECMA. But initially, it was very focussed on vendors, with a minimum $2000 price tag per year. Some early criticism is still interesting:

To me this makes it pretty clear, that this process is not an open one. If you're still not convinced, ask yourself these questions:

0. Can anyone tell Sun No? Can anyone keep Sun from putting something into the spec they want to put it in? Or put something in that Sun wants to keep out?

1. Can Sun's enemies (e.g. Microsoft, HP, etc.) participate in this process on an equal footing with Sun? Can they even participate at all?

When you actually read the fine print, what the Java Community Process says is that Sun agrees to let other companies contribute their time, money, and knowledge to help Sun do what it wants to do anyway. That may be intelligent business, but it's not an open, community based process for developing standards.

In hindsight, Sun's choices to avoid ISO and ECMA look reasonable. Java was not that established, and fast moving technology often doesn't fit well in standards bodies. And the threat from Microsoft was very real. Thus the JCP was better than nothing. It wasn't an open standards body though.

The Apache Software Foundation (ASF) did not participate initially but later played a part. In the lead up to JavaOne 2002, the Apache Software Foundation worked with Sun to ensure that specifications from the JCP could be implemented in Open Source. On stage announcement (large mp4 file) and Press reports:

The biggest news of this year's JavaOne was delivered Tuesday morning by Jason Hunter, an Apache Software Foundation vice president, co-creator of JDOM, and author of the popular O'Reilly Servlets book. Flanked by Sun CEO Scott McNeally and Sun vice president Rob Gingell, Hunter outlined an agreement negotiated between Sun and Apache that has broad-ranging implications to developers and to the future of Java itself. First, all in-progress and future Sun-led Java Specification Requests (JSRs) will be made available under a license that allows for open source.

In addition, key JSRs that have already been released will have their license altered to this newer, more open license. Even JSRs not being led by Sun can release their reference implementations under an open source license. Finally, Test Compatibility Kits (TCKs) for Sun-led JSRs will be made available for free to qualifying open source and academic groups.

There is a further important implication of Sun's statement that "Sun will modify the specification licenses of all the JSRs currently in progress to reflect Apache's requirements as met in the new draft JSPA." The JSPA is the legal agreement signed by members when they join the Java Community Process. Hunter points out that the draft JSPA includes the requirement that the TCK be licensed separately from the Reference Implementation (RI). In the past, commercial interests, which used to have to license the RI and TCK together, were bound by some interesting legal issues by having the RI source. Under the new agreement, they can now pay just for the TCK. This will help JBoss, for example, which can't get the TCK because it's currently only provided with the RI; they can't see the RI and remain independent.

This agreement from 2002, and the associated updated JSPA legal agreement, are the defining legal basis for the ASF's actions today.

The actual JSPA says.

Other than as set forth above, the Spec Lead agrees not to impose any contractual condition or covenant that would limit or restrict the right of any licensee to create or distribute such Independent Implementations.

Since 2002, the ASF, and many others, have implemented JSRs using these rights. This includes Apache Tomcat, Geronimo, OpenEJB, MyFaces and many more. The ecosystem worked! And surely the community now had an Open Standards body for Java equivalent to ISO?

But, when the ASF started the Harmony project, Sun was not happy.

It decided to stop Harmony using a Field Of Use restriction on the testing compatibility kit. The aim was simple, if Harmony passed the tests, then it wouldn't be open source software. Thus the ASF couldn't release Harmony. It was legally clever. Except that it conflicted with the JSPA legal agreement, as outlined above.

After private negotiations went nowhere, the ASF talked to the JCP Executive Committee (EC). The EC supported the position of the ASF in two critical votes. Oracle voted in support of the position of the ASF in both votes.

By this stage, Sun was in financial trouble. The apparent threat from Harmony was that the Java ME licensing revenue would disappear, and since every last dollar mattered, Sun did not feel able to concede. Instead, Sun released OpenJDK as the GPLv2 implementation of Java, placating some like Richard Stallman.

But the dispute itself dragged on. And on. And on.

Until Oracle bought Sun.

At that point there was hope that the issue would be resolved. After all, Oracle's public position was in support of the ASF. But over time it became apparent that Oracle intended to make no change to the licensing offered. It had done a U-turn.

So why didn't the ASF sue Sun, then Oracle? Well, basically its a really bad idea for a not-for-profit to sue a mega corporation, no matter how good the case. (That said, it might still have been the better course of action)

And why did the Executive Committee fail to fix the problem? Because there is no dispute resolution process in the JCP. All legal agreements are between the member and Sun, now Oracle - because the JCP itself is just a department, not an actual legally recognised organisation.

What the EC could do was prevent the approval of the Java SE 7 JSR. And they did. While this isn't the whole reason why its been so long since Java SE 6, it is a major part of the story.

Once Oracle finally got to grips with the issue it made a decision to force Java SE 7 and 8 through, no matter what. Tim Peirels captured this in his resignation statement:

Add to that Oracle's expressed intent to proceed with the SE7/8 JSRs whatever the outcome of the vote, and one can only conclude that the SE/EE EC is never going to be more than a rubber stamp for Oracle. (The belligerent tone with which this message was delivered does not come across in the public minutes, but it was loud and clear over my phone connection.)

At the same time, the second strand of Oracle's plan was in action. IBM and Apple were being invited to join OpenJDK in leadership positions. Effectively, this was the sign that IBM would now vote through the Java SE 7 and 8 JSRs, irrespective of the ASF dispute.

However, even I was surprised at just how clear the mismatch between the Java SE 7 license and the JSPA was. Not only that, the license terms are inconsistent with the stated uses of the JSR itself.

Of course, none of this mattered. The EC corporate members, and their lackie Eclipse, had decided to pass the JSRs even though they were in violation of the legal agreements. This was now big company politics, and if the ASF had to go, then it had to go.

Doug Lea resigned just before the vote. Tim Peirels just after. And today, the ASF joined them.

After all, there is no point helping to write specifications that you aren't allowed to implement.

But were they right to declare the JCP is dead?

The first ASF claim is that the JCP is not an open standards organisation because there are restrictions made in the commercial interests of one party that prevent another from producing an implementation. The second ASF claim is that the EC failed to perform its duty to enforce the rules and to defend a fellow member.

By approving Java SE 7, the EC has failed on both counts : the members of the EC refused to stand up for the rights of implementers, and by accepting Oracle's TCK license terms for Java SE 7, they let the integrity of the JCP's licensing structure be broken.

The Apache Software Foundation concludes that that JCP is not an open specification process - that Java specifications are proprietary technology that must be licensed directly from the spec lead under whatever terms the spec lead chooses; that the commercial concerns of a single entity, Oracle, will continue to seriously interfere with and bias the transparent governance of the ecosystem; that it is impossible to distribute independent implementations of JSRs under open source licenses such that users are protected from IP litigation by expert group members or the spec lead; and finally, the EC is unwilling or unable to assert the basic power of their role in the JCP governance process.

But none of this definitively means that the JCP is dead.

Oracle's public argument is that Java needs to move forward:

Last month Oracle renominated Apache to the Java Executive Committee because we valued their active participation and perspective on Java. Earlier this week, by an overwhelming majority, the Java Executive Committee voted to move Java forward by formally initiating work on both Java SE 7 and SE 8 based on their technical merits. Apache voted against initiating technical committee work on both SE 7 and SE 8, effectively voting against moving Java forward. Now, despite supporting the technical direction, Apache have announced that they are quitting the Executive Committee. Oracle has a responsibility to move Java forward and to maintain the uniformity of the Java standard for the millions of Java developers and the majority of Executive Committee members agree. We encourage Apache to reconsider its position and remain a part of the process to move Java forward. ASF and many open source projects within it are an important part of the overall Java ecosystem.

For me, this is very hollow. The reference to "technical merits" covers the fact that many members used their comments to object to the licensing. And frankly, Oracle were going to proceed whether or not the EC voted "Yes".

My conclusion is that the EC should have voted "No" and forced Oracle to run Java SE 7 and 8 outside the JCP, thus preserving the integrity of the EC and the JSPA license. And this action would have had zero effect on "moving Java forward".

Since the EC voted "Yes", they tacitly accepted Oracle's right to break the JSPA legal agreement when it is in their commercial interest.

Given that the ASF has no commercial axe to grind, they made the sensible choice to leave. And since the EC failed to act as the leaders of the industry it is entirely reasonable to say that the JCP is now a sham body where legal agreements mean little.

Thus essentially whether you consider the JCP is dead or not depends on what you believe the JCP is.

Since 2002, I have essentially seen the JCP as a vendor-neutral open standards body, the Java specific equal of ISO. Clearly, it can no longer be viewed as that.

But others have viewed it more as a useful tool for influencing the owner of Java, where the output sometimes allows the creation of a competitive ecosystem around a specification. Viewed this way, the JCP is still entirely feasible.

Certainly, Doug Lea saw it as the former:

I believe that the JCP is no longer a credible specification and standards body

So, is the JCP dead? Well, it will probably limp on for a while. And if the second view of what it is takes hold, then it may have some future as far as big corporates are concerned.

But it cannot now be seen as an Open Standards Body.

So its both dead and undead. A zombie.

Summary

Its the end of an era. An era of hope that the JCP would be Java's ISO, producing truly Open Standards.

So as that era closes we look forward to the new closed era of Java. Where its Oracle's way or the highway.

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

Java SE 7/8 passed

So, the Java SE 7 and 8 votes passed.

Java SE 7 passed by 12 votes to 3 (Apache, Google and Tim Peierls voting against).

Java SE 8 passed by 12 votes to 3 (Apache, Google and Tim Peierls voting against).

Project Coin passed by 13 votes to 1 with 1 abstention (Apache voting against and Tim Peierls abstaining).

Project Lambda passed by 13 votes to 1 with 1 abstention (Apache voting against and Tim Peierls abstaining).

But it looks like many of the voters were unhappy.

Java SE 7 vote results

When voting for a JSR there is the opportunity to leave comments. These often indicate the true feelings of voters more than the actual Yes or No. Here are the actual vote comments for Java SE 7 (the Java SE 8 comments are similar but with reference to OSGi):

On 2010-12-03 Peierls, Tim voted No with the following comment:
Changing my vote from "Abstain" to "No" to register my extreme disappointment with Oracle's failure to address EC questions about the licensing terms of this JSR.
------------------------------------------------------------------------------
On 2010-11-17 Google Inc. voted No with the following comment:
While we support the technical content of this JSR, Google is voting no because of its licensing terms. As per the JCP resolutions of 9/25/2007 and 4/7/2009, "TCK licenses must not be used to discriminate against or restrict compatible implementations of Java specifications by including field-of-use restrictions on the tested implementations or otherwise. Licenses containing such limitations do not meet the requirements of the JSPA, the agreement under which the JCP operates, and violate the expectations of the Java community that JCP specs can be openly implemented." Most EC members, including Oracle, voted for both of these resolutions. But the proposed license clearly violates them in Exhibit A, Section II.

It would be wrong to condone the inclusion of field-of-use restrictions in a TCK license (which violates the above resolution and the JSPA) by voting for this JSR. We were initially reluctant to vote no because we do not want to delay progress of the Java platform. But this concern was made moot by Oracle's statement at the JCP meeting of 10/4/2010 that they intend to move forward with the release outlined in this JSR with or without the approval of the JCP.
------------------------------------------------------------------------------
On 2010-11-17 Oracle voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-11-29 SAP AG voted Yes with the following comment:
While we are disappointed that Oracle has decided to deny Apache a TCK license for Java 7, SAP's vote is strictly based on the technical merits of the Java 7 specification, not on its license terms. While we believe it is important for Java 7 to proceed now, we want to express our disagreement about Oracle's decision regarding the TCK for Apache. The reason that was provided to the EC was that Java compatibility could no longer be enforced with code shared under a permissive open source license. As the new steward of the Java language, we respect Oracle's right to license their intellectual property under terms that support their strategy of how to evolve the Java ecosystem. However, we believe that the additional potential for innovation in open source communities outside of OpenJDK well offsets the risks as already demonstrated in the Java Enterprise space.
------------------------------------------------------------------------------
On 2010-11-30 Hewlett-Packard voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-02 IBM voted Yes with the following comment:
IBM's vote is based on the technical merits of this JSR and is not a vote on the licensing terms. IBM supports licensing models that create an open and level playing field by allowing third parties to create independent implementations of Java Specifications and that do not allow individuals or companies to exercise unnecessary control for proprietary advantage. We support open source as a licensing model for contributions in the JCP, and would hope others will support this direction. This comment is not necessarily directed at the current business or license terms for this JSR, however, it is a statement of IBM's preferred licensing model.
------------------------------------------------------------------------------
On 2010-11-30 Ericsson AB voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-01 Apache Software Foundation voted No with the following comment:
The Apache Software Foundation must vote no on this JSR. While we support the technical contents of the JSR, and earnestly support the need for the Java platform to move forward, we cannot in good conscience vote for this JSR because :

a) This JSR's TCK license includes a "Field of Use" restriction that restricts commonplace and mundane use of independent implementations, a licensing element that not only is prohibited by the JSPA but also has been unanimously rejected by the majority of the members of the JCP EC - including Oracle - on several occasions. We can only speculate why Oracle included such an element, but we believe that an open specification ecosystem must be independent of - and protected from - any entity's commercial interests.

b) On process grounds, this JSR is in conflict with it's own TCK license. The JSR explicitly states that Java SE is targeted for, among others, embedded deployments. Yet the TCK license specifically prohibits such usages (for example, netbooks) of tested independent implementations. We find this to be a misleading legal trap for potential implementers, and believe that any independent implementation that passes the TCK should be able to be used and distributed under whatever terms deemed fit by the implementer.

c) The spec lead has ignored repeated requests from multiple EC members for and explanation of both a) and b)

d) The spec lead - Oracle - is in breach of their obligations under the JSPA by continuing to provide a TCK license for Apache Harmony under terms that allow Apache to distribute its independent implementation under terms of its choice. We do not believe that anyone that willfully fails to meet their contractual obligations under the JSPA should be allowed to participate as a member in good stating in the JCP. The rules apply to everyone.

While we understand that it's Oracle's stated intent to move forward irrespective of the EC's decision, we urge Oracle to fix the above-mentioned issues, and continue to work with the members of the JCP within the structure of the JCP to keep Java a vital and viable platform.
------------------------------------------------------------------------------
On 2010-12-02 Eclipse Foundation, Inc voted Yes with the following comment:
Eclipse is disappointed with the continuing issues around Java licensing. The unresolved TCK licensing issue with the Apache Software Foundation is a symptom of the fundamental problem with FOU restrictions on the Java platform. Our vote is based entirely on the premise that improvements and evolution are required if the Java platform is to remain viable. In addition, we remain concerned that the future of Java modularity may fail to adequately reflect the requirements of the existing OSGi community and ecosystem. Future votes on these JSRs will reflect this concern.
------------------------------------------------------------------------------
On 2010-12-02 Fujitsu Limited voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-04 RedHat voted Yes with the following comment:
Red Hat's vote is based solely on the technical merits of the JSR. We believe that this JSR is important for the industry at large and that further delays risk fracturing the Java landscape further. However, we are extremely disappointed with the license terms and that a more open license has not been adopted by the Specification Lead. We continue to believe that the TCK should contain no "field of use restrictions", as originally raised by Apache with regard to another JSR during the development of EE6 (i.e. the SE TCK licensing). As a result, this approach risks limiting adoption of this and subsequent JSRs by a wider audience and the fracturing that we mentioned earlier could still occur. We hope that all Specification Leads will take this into account in the future and rank the viability of the Java Community higher than one individual member's abilities to monetise the platform.
------------------------------------------------------------------------------
On 2010-12-05 VMWare voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-06 Keil, Werner voted Yes with the following comment:
While I'm equally dissapointed with the ongoing license dispute and the effect this and other issues had on the actual content and scope of Java 7 (I am not the only one who feels this is technically hardly worthy of a version major compared to especially Java 5) I believe, it is a necessary and long overdue step towards the future of Java. I share discomfort with less talked about, but nevertheless tedious problems like the lack of modularity in SE7 and its effect on dependent JSRs like EE.
------------------------------------------------------------------------------
On 2010-12-06 Intel Corp. voted Yes with no comment.
------------------------------------------------------------------------------
On 2010-12-06 Credit Suisse voted Yes with the following comment:
Credit Suisse's vote is purely on the technical content. We strongly demand open standards and an active community around Java as we selected Java SE & EE as primary pillars for our application development (as many others in the industry do). The current battle around licensing term, however, reveals that Java never actually was an open standard. FOU restrictions clearly discriminate open source implementations and prevent competition, and with that, innovation in that space. While Java had a considerable head start, it lost a lot of momentum over the last years. Fragmentation (or a fork) of the language and its platforms are clearly not desired. But today, customers are already facing competing models for developing enterprise applications (e.g., Spring, OSGi, Java EE). The main problem, in our view, is the lack of modularization, clear delineation of Java IPs owned by Oracle and truly open standard extensions, and the ignorance of developments outside of the JCP (even though OSGi has a JCP blessing). The OpenJDK framework is not sufficient for all aspects of the language. Java must be kept interesting for researchers and universities: researchers not only contribute to the standards (e.g., Doug Lea for concurrency or Michael Ernst for type annotations) but also decide on the languages (and paradigms) that are taught at universities -- and this in the end determines the knowledge and mindset we acquire with our software engineers. While we recognize Oracle’s intellectual properties around Java, we strongly encourage Oracle to re-think its current position around licensing terms. We strongly support open source as a licensing model for contributions in the JCP.

------------------------------------------------------------------------------

There is a lot in those comments to understand, and I can't cover it all now.

I do note Time Peierls decision (as an individual) to change his vote from "Abstain" to "No" and the reason given. Clearly, Oracle were asked to explain their licensing terms and how they square with the JSPA, and with the JSR text itself, and have failed to do so. My interpretation is that Oracle no longer felt the need to justify its actions.

I also castigate Hewlett-Packard, Ericsson AB, Fujitsu, VMWare (SpringSource) and Intel for not even having the courage to justify their actions (which are in direct opposition to previous votes). I will note that Intel has previously been a strong Apache supporter. However, I understand that the Intel representative on the JCP was changed a few months back, prior to the vote (no public source to confirm this as far as I know Update: the executive committee members list has been updated to show the change, which happened since July).

I am disappointed in all the "Yes" voters. Clearly Oracle intended to move Java SE 7 forward irrespective of the vote here. Thus voting "No" would have had no adverse consequences on the forward momentum and technical progress of Java. Since the main role of the Executive Committee, distinct from Expert Groups, is to consider the business implications it is clear that each company that voted "Yes" has given tacit approval to the business practices of Oracle. I suspect that they will come to regret that decision. Give a bully an inch and they will take a mile.

Summary

Today, Oracle won its battle in the JCP. But it was a stupid battle to have. Submitting a JSR whose licensing terms are in conflict with the JSR itself and with the JSPA was simply unnecessary. Voting "Yes" to it was simply cowardly.

The huge irony is that Oracle claims to support Java because all of its money making systems are written in Java, thus it is in its own interests to keep Java vibrant. Yet the strong-arm actions here simply push people away and harm that vibrancy. Go figure.

We should expect the response from the Apache Software Foundation soon.

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