Devoxx whiteboard votes 2010

As usual at Devoxx, there were a number of Whiteboard polls. These aim to capture the sense of the community and are of course only semi-scientific!

This year, picking questions was a little tricky, given the current disputes. I decided to ask questions focussed on specific topics and provide a choice of responses. Of course, you can never cover all valid responses, so there was always a comment area for extra opinions.

The +n notation after a comment means that n other people agreed with the comment. The <- notation means that what follows is a comment on the previous comment.

How do you feel about the Oracle vs Google lawsuit?

"It does not affect me. I do not care"	10
"It is necessary to avoid fragmenting the Java platform"	16
"There may be a case but legal action is a bad idea"	62
"I really care - its a dumb idea"	116
"It is encouraging me to look at non-Java platforms"	9
Total votes cast	213

View the photo. There were also some comments:

• The lawyers will win. +3
• Google should buy Java/Oracle
• Google should create/drop Java+
• $$Larry Ellison needs a new yacht. +2
• Ban software patents. +7
• Dimemma: Its fun to watch
• Big powerplay for mobile space
• Crazy SCO move!
• Fight!
• I know a good mediator: Equilon
• Patent trolls
• Patent should help small reality to contribute! Not help huge industry to black mail each other! <- (Ponies and Rainbows anyone?)
• What's JSR nnumber for Android!

A very clear answer was provided on this topic - devoxx attendees that voted were solidly against the lawsuit (over 87%). While a high number thought there might be a case even more thought the lawsuit was just plain dumb. If Oracle wants developers on its side, it is clear that the lawsuit is a problem. As always, the comments were entertaining too.

Should Java 8 or 9 be backwards incompatible?

"Yes! Its time to remove some old stuff to make room for new"	185
"Maybe! Some SMALL incompatible changes would be good"	35
"No! Backwards incompatibility is essential to Java"	27
"I don't care, I'll just use whatever I am given"	4
Total votes cast	251

View the photo. There were also some comments:

• Java NG, Bytecode should still be usable. +5
• Please cleanup IO
• Cleanup. Pe Java 5 stuff
• Remove java.util.Date. +1
• Corbe pollutes APIDOC <- so use Jigsaw
• Remove ESB2 compatibility +1

Clearly, a majority of voters wanted some form of backwards incompatibility (over 87%). This is a remarkably clear result and was more positive than I expected.

How do you feel about the JCP?

"It is very important and will continue to be"	3
"Everyone needs to start working together"	36
"It needs radical reform"	24
"It is no longer relevant"	5
"It is F***ed" (added by a conference attendee)	12
"I don't know anything about it" (added by a conference attendee)	8
Total votes cast	88

View the photo. There were also some comments:

• Who cares? OSS already demonstrates "de facto" standard to override JSR. +2
• Hibernate is OS,Hibernate gave birth to JPA, JPA is standard, Hibernate implements the standard (<- Mostly), Hibernate is still OS
• Design by committee
• Will be James Brown, doubt it. "Get in it, Get involved, Everybody get funky"
• Only good for big vendors, at the detriment of developers
• Get out of the way. Turn in to a real open COMMUNITY!
• The "new" mantra is cool: "Test stuff in the community first then standardize what really works"

Opinion was split here, on a relatively low turnout. Clearly compromise is still valued, but some believe it may be too late.

Does Oracle believe in the Java community?

"Yes! They are investing $millions"	10
"Maybe! They just see it differently to Sun"	83
"No! They are severly damaging the community"	36
"I don't care, the community is not important"	2
Total votes cast	131

View the photo. There were also some comments:

• Bad communication, but they really wat to learn. +1
• Google and ASF should join forces and start working on BIJava cause Oracle will never have the balls to do it
• JavaOne needs to be 1st class citizen again! +1
• Demonstrate first: Free talk +3
• Trust must be earned
• Larry Ellison pick up the phone, Eric Schmidt pick up the phone, Geir Magnusson Jr pick up the phone, DEAL
• <-(someone forgot to call me!)
• Java community is watcing! If Oracle f****up something new might come out and takeover
• Communication is the key!

The message here seems to be that many are still willing to give Oracle a chance. I'm interested in those that do not believe community is important ;-)

How should Oracle make money from Java?

	Paid for	$Free
"Core JVM"	0	39
"JVM tools (JRockit mission control)"	26	10
"IDEs"	7	24
"Application server (Webloic)"	30	4
"Middleware (ESB/Fusion)"	31	3

View the photo. There were also some comments:

• Not +2 ("not" as in should not make any money I presume)
• Stop paying lawyers! <- LOL
• In whatever way works to max income

This vote only started on Thursday, hence the lower voting figures. The results ought to be predictable, but clearly a few want $free everything. In general it looks like Oracle's paid vs $free choices are about right.

OpenJDK is now the "heart" of Java

"I will contribute to OpenJDK"	12
"I like OpenJDK but don't want to contribute"	16
"The OpenJDK GPL license is uncertain because of Oracle's patents"	31
"I don't believe OpenJDK should be the only Java SE implementation"	37
Total votes cast	96

View the photo. There were also some comments:

• Troll? +1
• A clear statement from Oracle is needed on WHY they do not want to make it possible for others to have Java implementations (Harmony). Would like to hear BUSINESS reasons. +8
• <-Maybe mreinhold could explain?
• More communication is what will solve the problems & stop damaging speculation
• Oracle should make TCK available w/o field-of-use restrictions. +5
• Harmony FTW, keeps them true. +1
• It should be. +1
• Should be LGPL

There is definitely support here for other Java SE implementations, yet not a huge number of votes overall. I suspect that amongst those that know the story it matters, but in general it doesn't. I also find the (popular) comment for an explanation interesting.

What is your favourite non-Java language?

Scala	69
Groovy	42
Python	22
Javascript	22
Ruby	16
Clojure	8
Objective C	7
Smalltalk	7
PHP	5
C	5
C++	5
Perl	5
Fantom	3
C#	3
Forth	3
Z80 assembler	3
Human language	3
Body language	2
CSS	2
Pascal	2
BAS#	2
Haskell	1
Visage	1
Erlang	1
Modula 3	1
MPS	1
Prolog	1
Eiffel	1
InterCal	1
MatLab	1
BPMN 2	1
Lisp	1
LiveCode	1
HyperTalk	1
Total votes cast	244

View the photo. Last year Groovy came top, this year it is Scala. One point to bear in mind is that Groovy conferences are now well established, so possibly those most dedicated to Groovy nonw attend those. Or maybe Scala is getting more popular. And I was personally surprised to see how popular Python is.

Summary

Devoxx votes are nothing more than a snapshot of opinion by a proportion of the attendees of Devoxx. Yet despite the caveats, their results can be interesting. Its the power of the community!

Java SE 7 and 8 JSRs published

Following yesterday's statements from Oracle and Apache, the meaty JSRs are now published and announced by Mark Reinhold.

I’m pleased to note the submission of four new Java Specification Requests to the Java Community Process:

* JSR 334: Small Enhancements to the Java Programming Language, by Joe Darcy with help from Jon Gibbons, Maurizio Cimadamore, and many others in Project Coin;
* JSR 335: Lambda Expressions for the Java Programming Language, by Brian Goetz with help from Alex Buckley, Maurizio, and others in Project Lambda;
* JSR 336: Java SE 7 Release Contents, for the enormous team effort that is JDK 7 (the first half of Plan B); and, finally,
* JSR 337: Java SE 8 Release Contents, for the eventual JDK 8 (the rest of Plan B).

These JSRs have been a long time coming. They’re now—finally—on the JCP Executive Committee ballot for approval; results should be available in two weeks.

My thanks to everyone who’s contributed to the related OpenJDK Projects.

Cool! Java is moving forward! And JSR-310 is proposed for Java SE 8!

But, lets take a peek at the interesting stuff... the licensing terms. (OK, its not really that interesting unless you want to understand the raging Java disputes...)

Firstly, the licenses are provided in Word Document format! (See section 2.18 of the JSR page for the links)

Its late here, so I only have limited time to evaluate the licenses. At first glance, the Specification and Reference Implementation licenses look fairly normal and bland (but I may be wrong). The interesting one is the TCK (testing kit) license.

I emphasise that this should be considered to be notes on the TCK license based on a relatively quick reading. If you read this blog and reference this topic/story in another blog or article, you are advised to read and examine the original license text yourself, or include a suitable caveat.

The famous "Field of Use" is an explicit part of the license:

1.4 "Exhibit A" means collectively Exhibits A-1 through A-n which incorporate into the Agreement the specific terms and conditions for each TCK licensed hereunder.

1.6 "Field of Use" means the relevant market segments for products tested by a particular TCK for a Java Environment Specification as specified in the applicable Exhibit A(s).

The "Java Environment Specification" is defined, covering Java SE:

1.8 "Java Environment(s) Specification" means a Java Specification that defines a baseline API set that provides a foundation upon which applications and other Java Specifications can be built. For example, and not by way of limitation, Java Environment Specifications include: (a) “Platform Editions” such as the Java Platform, Standard Edition ("Java SE"); Java Platform, Enterprise Edition (“Java EE”); and Java Platform, Micro Edition (“Java ME”) Specifications; (b) “Configurations” such as the Connected Device (“CDC”) and Connected Limited Device (“CLDC”) Configurations; and (c) “Profiles” such as the Mobile Information Device (“MIDP”) Profile.

The definition of a "product" contains what looks like an unusual part (highlighted). It appears that a "product" must meet three criteria beyond the basic ones:

• "have a principal purpose which is substantially different from a stand-alone implementation of that specification"
• "represent a significant functional and value enhancement over any stand-alone implementation of that specification"
• "not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification"

I believe that Apache Harmony would fail all three of these tests (were the project to try and implement this JSR, which they probably won't). Since a "stand-alone implementation" would be either OpenJDK or OracleJDK, the principal purpose of Harmony is clearly the same (not substantially different), Harmony does not offer significant functional enhancement, and Harmony would be marketed as a replacement for OpenJDK/OracleJDK.

1.12 "Product(s)" means a Licensee product which: (i) fully implements the Java Specification(s) identified in Exhibit A including all its required interfaces and functionality; (ii) does not modify, subset, superset or otherwise extend the Licensor Name Space, or include any public or protected packages, classes, Java interfaces, fields, methods or constructors within the Licensor Name Space other than those required/authorized by the Specification or Specifications being implemented; (iii) passes the TCK (including satisfying the requirements of the applicable TCK Users Guide) for such Specification; and (iv) neither derives from nor includes any of Oracle’s source code or binary code materials which implement any portion of the Java Specification, except for code contributed by Oracle to an open source project (e.g. Apache’s “Tomcat” project) and that is rightfully (i.e. pursuant to a separate and appropriate license) included in the product to be tested. In addition, to be a Product, a Licensee product that implements a Java Environment Specification must: (a) have a principal purpose which is substantially different from a stand-alone implementation of that specification, while the value-added portion of the product operates in conjunction with the portion that implements the Java Environment Specification; (b) represent a significant functional and value enhancement over any stand-alone implementation of that specification; and (c) not be marketed as a technology which replaces or substitutes for a stand-alone implementation of that specification.
(My highlights)

Criteria are given as to what not to do. This indicates that no one may distribute code that implements the specification unless it is part of a product, as defined above. Given Apache Harmony cannot be a product, it cannot be distributed.

(b) Additional Limitations. Except as otherwise set forth in Exhibit A, Licensee may not:
...
(v) distribute code which implements any portion of the Java Specification unless such code is included in a Product within the meaning of Section 1.12 and unless, for each new release of a Product by Licensee, such Product passes, in accordance with the Documentation (including the TCK Users Guide), the most current TCK applicable to the latest version of the Java Specification and available from Oracle one hundred twenty (120) days before FCS of such version of the Product; provided, however, that if Licensee elects to use a version of the TCK also provided by Oracle that is newer than that which is required under this Section 2.1(b)(v), then Licensee agrees to pass such TCK;
(My higlights)

Were a court case to challenge the contents of the license, Oracle can at its discretion terminate the licence.

11.4 Partial Invalidity. If any of the above provisions are held to be in violation of applicable law, void, or unenforceable in any jurisdiction, then such provisions are herewith waived or amended to the extent necessary for the Agreement to be otherwise enforceable in such jurisdiction. However, if in Oracle's opinion deletion or amendment of any provisions of the Agreement by operation of this paragraph unreasonably compromises the rights or increase the liabilities of Oracle or its licensors, Oracle reserves the right to terminate the Agreement.

And Exhibit A contains the actual "Field of Use" terms. These specifically exclude wireless mobile telephones, kiosks and even netbooks (highlighted). Remember that any Field of Use restriction violates the OSI open source definition.

EXHIBIT A
TECHNOLOGY SPECIFIC TERMS AND CONDITIONS

I. Description of TCK, Test Tools and Documentation

A. Java Specification: Java Platform, Standard Edition, version 7 (“Java SE 7”), which includes mandatory standalone elements to the extent described and permitted in the Java SE 7 specification and which includes optional elements to the extent described and permitted in the Java SE 7 specification
...
II. Field(s) of Use: Products for use on “General Purpose Desktop Computers and Servers" meaning computers, including desktop and laptop computers, or servers, used for general computing functions under end user control (such as but not specifically limited to email, general purpose Internet browsing, and office suite productivity tools). The use of Software in systems and solutions that provide dedicated functionality (other than as mentioned above) or designed for use in embedded or function-specific software applications, for example, but not limited to: Software embedded in or bundled with industrial control systems, wireless mobile telephones, wireless handheld devices, netbooks, kiosks, TV/STB, Blu-ray Disc devices, telematics and network control switching equipment, printers and storage management systems, and other related systems are excluded from this definition.
(My highlights)

The published release must contain a note from Oracle emphasising the conditions on further distribution:

1. The following provision is added as subparagraph (viii) to the Additional Limitations set forth in Section 2.1(b):

(viii) distribute Products unless accompanied by the following notice from Oracle, where the notice is displayed in a manner that anyone receiving the Product will see the notice:

NOTICE FROM ORACLE:
If you redistribute the software licensed hereunder (including derivative works thereof) for your direct or indirect commercial gain, then we are not authorized to grant or otherwise pass through to you any licenses under Oracle applicable intellectual property or other rights, if any, and as a result any such use is a violation of Oracle’s applicable rights. Any redistribution of the software licensed hereunder (including derivative works thereof) must be compatible and branded with the appropriate compliance logo specified by Oracle and licensed by Oracle to you pursuant to a separate Trademark License required to be executed by you with Oracle.

Redistribution of the software licensed hereunder must retain this notice.

The cost of the TCK is specified. And it is cheap. So, none of the dispute is directly about money (indirectly is another matter!).

A. For Commercial Licensees: $100,000.00 (as of the Effective Date) per year. All fees shall be due upon execution of this Agreement. In addition, Oracle shall have no obligation to deliver or make available the TCK until such fees are received by Oracle.

B. For Qualified Not-for-Profits and Qualified Individuals: $0.

And thats it. Well, at least the parts I see as being interesting. But if you want to comment on this, you really should read it yourself!

Sadly, at 3am, I don't have time to contrast the TCK license with the JSPA.

To be honest, I'm surprised that the TCK license for Java SE 7 still contains any pretence that it can be implemented in open source by anyone other than Oracle. At least the restrictions are clear (and I suspect, but cannot prove, that very similar restrictions were offered for Java SE 5 in the Sun/Oracle vs Harmony dispute).

I personally expect these 4 JSRs to pass the JCP Executive Committee vote in two weeks time as I see no evidence that committee members are still up for a fight. If the vote passes, I expect the ASF will immediately leave the JCP.

I will leave the biggest amusing point until last. The TCK license conflicts with the JSR! The JSR itself says:

2.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This JSR defines a release of the Java SE platform targeted at embedded, desktop, server, and cloud environments.
(My highlights)

So, the JSR is targetted at embedded environments! That's not what the TCK license says ;-)

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

Oracle replies to the ASF

Oracle have responded to the Apache Software Foundation board statement.

Oracle nominated Apache for a seat on the Executive Committee in recognition of Apache's continued participation and valued contribution to the community. The recently released statement by the ASF Board with regard to their participation in the JCP calling for EC members to vote against SE7 is a call for continued delay and stagnation of the past several years. We would encourage Apache to reconsider their position and work together with Oracle and the community at large to collectively move Java forward. Oracle provides TCK licenses under fair, reasonable, and non-discriminatory terms consistent with its obligations under the JSPA. Oracle believes that with EC approval to initiate the SE7 and SE8 JSRs, the Java community can get on with the important work of driving forward Java SE and other standards in open, transparent, consensus-driven expert groups. This is the priority. Now is the time for positive action. Now is the time to move Java forward.
Don Deutsch, Vice President of Standards and Architecture

Update 16 Nov: And the ASF responded to the response!!! Here it is:

Oracle statement regarding Java: "Now is the time for positive action (and) to move Java forward."

The ball is in your court. Honor the agreement.

I've used this blog to highlight the role of politics in the development of Java, especially in this dispute. Personally, I'm glad that this story is coming to an end, as I can write more code and less blogs!

Basically, I see this statement from Oracle as expected and well written. Expected, because it simply states the known position. Well written, because it puts a spin on what Apache actually said.

The key sentence is "Oracle provides TCK licenses under fair, reasonable, and non-discriminatory terms consistent with its obligations under the JSPA."

Bear in mind that the TCK offered would result in the tested Harmony code not being able to be released under any open source license, not just the Apache license. See my previous detailed explanation with pictures. I'm almost amused that anyone would describe those terms as "fair, reasonable, and non-discriminatory".

Actually, the sentence doesn't talk about Harmony at all. Technically, it doesn't claim that any fair terms were offered to Harmony. All the sentence actually claims is that Oracle provides TCK licenses under fair terms, which is true for every other JSR expect Java SE. Yes, I really am reading this statement as a lawyer could!

I'd also point out Don's previous actions from 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."

Oracle (Don) voted yes

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

Oracle (Don) voted yes

Only Don can truly answer why his opinion changed once he was in a position to action what he called for.

So what next?

Well, barring an earthquake, the Java SE 7 vote will proceed, the vote will go Oracle's way, and the ASF will leave the JCP entirely. I do not see either the ASF or Oracle slowing down the Java SE 7 timetable at this point.

Finally, we sometimes need to remember that Oracle continues to invest heavily in Java, from ME to SE to EE to FX. We all want an end to stagnation. I simply object to the approach chosen to end the stagnation.

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

ASF ready to leave JCP

The Apache Software Foundation board has released a statement regarding the JCP.

The Apache Software Foundation (ASF) is proud to announce that it has been ratified for another three-year term on the Java Community Process (JCP) Executive Committee. Receiving support from 95% of the voters, this election allows the ASF to continue its 10 year effort to help bring transparency and openness to the JCP as well as ensure that Java specifications are able to be independently implemented and distributed under open source licenses.

We are grateful for the strong support from the community, and believe it is a validation of the work the ASF is doing in the JCP. Our efforts to transform the JCP into a truly open specification ecosystem help strengthen the value of Java for everyone -- for implementors of open source projects such as those found at the ASF and elsewhere, for students, educators and academics using Java for teaching and research, for independent software vendors that build innovative products and services on Java, and for commercial users in all areas of economic activity that depend on Java to run and grow their businesses.

Through the JSPA, the agreement under which both Oracle and the ASF participate in the JCP, the ASF has been entitled to a license for the test kit for Java SE (the "TCK") that will allow the ASF to test and distribute a release of the Apache Harmony project under the Apache License. Oracle is violating their contractual obligation as set forth under the rules of the JCP by only offering a TCK license that imposes additional terms and conditions that are not compatible with open source or Free software licenses. The ASF believes that any specification lead that doesn't follow the JCP rules should not be able to participate as a member in good standing, and we have exercised our votes on JSRs -- our only real power on the JCP -- accordingly. We have voted against Sun starting and continuing JSRs, and have made it clear that we would vote against the JSR for Java SE 7 for these reasons.

In light of Oracle Corporation failing to uphold their responsibilities as a Specification Lead under the JSPA and breaking their signed covenants with the Apache Software Foundation that are the conditions under which we agreed to participate in the JCP, we call upon the Executive Committee of the JCP to continue its clear, strong and public support for Java as an open specification ecosystem that is a level playing field for participants in order to ensure that anyone -- any individual or commercial, academic or non-profit entity -- is able to implement and distribute Java specifications under terms of their choice. Specifically, we encourage the other members of the JCP EC to continue with their support of our position regarding Oracle, and vote accordingly on the upcoming Java SE 7 vote.

The ASF will terminate its relationship with the JCP if our rights as implementers of Java specifications are not upheld by the JCP Executive Committee to the limits of the EC's ability. The lack of active, strong and clear enforcement of those rights implies that the JSPA agreements are worthless, confirming that JCP specifications are nothing more than proprietary documentation.

I think there is little to add (I've reproduced verbatim). I do hope that Oracle take one last look at what is about to happen here and offer some form of meaningful compromise. It may be too late, but the impact of this is potentially serious.

This new statement appears to superceed the previous statement.

For the record, although I am an Apache member, I was not party to the specific decision making in either statement.

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

Premium JVM thoughts & Open JVM proposal

Some thoughts on the Premium JVM and the benefits of freeing the JVM separate from Java SE.

Premium JVM

The JVM is a technology we sometimes forget to talk about, yet it is central to development on the Java platform. Like most other Java technologies, it has a JSR - #924

Clearly, all the other languages on the JVM - Fantom, Groovy, JRuby, Clojure, Scala ... - all rely on the JVM primarily. Each of them also rely on the Java libraries to some degree, but the JVM is their core, and many of them would like to only depend on the JVM in an ideal world.

At QCon San Francisco, it is reported that Adam Messinger announced in passing that there would be a premium version of the JVM alongside the gratis (free) version. This raises many questions:

• Will the premium and gratis version be released at the same time?
• Will gratis version still support the same range of operating systems?
• What extra features will the premium version have?
• Is this only management features?
• Or are there performance features?
• Who is the target market?

My concern is that once you have the split, there will be a product manager for the premium version. Their bottom line and job success will depend on moving people from gratis to paid. They will therefore lobby against adding to the gratis version and rachet up the cost of the paid version.

Logically, this is just an extension of the JRockit product and shouldn't be a threat. Lets hope that the answers to the above are suitable and provided soon so the community has reassurance.

Update 8th Nov: This Oracle press release from September 2010 indicates the underlying situation - that "premium" simply refers to a continuation of the JRockit paid for elements. I still hope that more detailed information can be provided.

Oracle is currently working to merge the Oracle Java HotSpot Java Virtual Machine (JVM) and the Oracle JRockit JVM into a converged offering that leverages the best features of each of these market-leading implementations. Oracle plans to contribute the results of the combined Oracle Java HotSpot and Oracle JRockit JVMs to the OpenJDK project. The Oracle JDK and Java Runtime Environment (JRE) will continue to be available as free downloads, with no changes to the existing licensing models. Premium offerings such as JRockit Mission Control, JRockit Real Time, Java for Business and Enterprise Support will continue to be made available for an additional charge.

Update 10th Nov: This further update from Oracle provides a public HTML summary of what was announced at JavaOne. I understand this should be considered to be the definitive word on the strategy, and effectively confirms that the "premium JVM" name is just the continuation of those parts of JRockit that were already paid for.

Open JVM

Since the recent news that Oracle will not allow Apache Harmony to complete as an implementation of Java SE, I've noticed a number of tweets and blogs questioning the whole JVM platform, not just Java.

There are now people considering moving to the .NET CLR or other platforms away from the JVM. This cannot be a good thing for Oracle!

As Oracle have stated, the community cannot have an open standard for the Java SE platform. If we accept that (and given the history and legalities we shouldn't) then what is the next best thing?

What if there was an open standard for the JVM?

The JSR exists - 924. All Oracle needs to do is allow it to be freely implemented, without Field Of Use or any other limitation, and independently of the rest of Java SE (which I don't believe is possible at the moment).

Update: I asked for clarification from Henrik Stahl of Oracle. He replied to me by email giving me permission to reproduce this here:

Stephen, You asked me if it was possible to implement a JVM without Java. I looked into it and there seems to be technical showstoppers. The JVM specification was clearly written with Java in mind. There are dependencies in the spec on java.* classes such as Object, ClassLoader and various exceptions. A JVM cannot be implemented according to the spec without these classes. So it's not possible for you to implement a JVM without *some* Java. And if you have *some* Java you probably have to implement *all* of Java, since subsets are discouraged due to fragmentation concerns. (Disclaimer: I'm no lawyer. This is my personal interpretation, and is not an official Oracle position.)"

I don't see this as threatening to Oracle in the same way as Java SE is (at least not threatening technically - politically its always hard to tell). The JVM is a simple input/output machine, theoretically easy to test for compatibility independent of the rest of Java SE (please contradict me in the comments if you have additional knowledge here).

Making this available has huge benefits: It is a good PR move, softening the tension in the Java community. It allows part of Apache Harmony to be released properly. It ensures true competition in JVM performance and additional features in the same way as Java EE has benefitted. It also removes any lingering concerns that the gratis/premium version of the JVM could be abused.

I've always thought that Sun missed a huge trick in not getting the JVM adopted as the heart of language programming in all browsers. Technically, Javascript could run on top of the JVM embedded within the browser. Sounds odd? Well not if the JVM were a freely implementable specification without restriction, capable of being extended, tweaked and integrated in different ways.

For example, a JVM could be written that is more modular, or slimline more suitable for different environments, such as one designed explicitly for a world where Javascript was the primary language it ran. Or a JVM could be implemented directly on top of the CLR or LLVM, or integrated within. Or a JVM could even implemented in another language like Ruby or Javascript rather than C (I remember seeing this once, so its technically possible!).

There is a huge set of opportunities here!

And for Oracle, that would mean embedding the JVM bytecode definition at the heart of many more areas. Which would reconfirm the JVM as the core technology today.

Hey, if browser vendors adopted it, we could write real code in the browser instead of pesky Javascript! Which would surely be a better technical solution than cross compiling JavaFX down to Javascript.

Summary

The premium JVM concept should just be JRockit continued. But, given recent actions by Oracle, there has to be concern that its the first move to charging for the "real" JVM. Clarification is needed. Update: see above

One way to turn the situation around would be to make the JVM freely implementable separate from Java SE. Apache Harmony would benefit, lessing tensions, but so would many other environments. A JVM implemented using the CLR or LLVM would be immensely useful. And maybe, just maybe, we could get to write real code in browsers on a multi-platform VM instead of Javascript.

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

JCP election result & commentary

The JCP election are out. What do they tell us?

JCP election results 2010

The JCP election results are now available.

In the ratified seats (were Oracle chooses who stands), Apache was confirmed by 95% of voters and Red Hat by 87%. Hologic was not ratified, receiving only 33% yes votes. For ME, all three companies were ratified (although the web page indicates that TOTVS only got 49%, which if true means they should not have been ratified - something that needs clarification - Update: see Patrick Curran's comment for the valid explanation).

In the open elections (any JCP member can stand), Google (33%) and Eclipse (27%) were elected, with Bob Lee not elected in third (21%). For ME, Aplix (30%) and Stefano Andreani (27%) were elected. (Note that each voter received 2 votes for SE and ME in this phase, so its slightly unclear what the percentages mean. I'd assume that Google was supported by 66% of voters, but this isn't clear)

As Hologic was not ratified, Oracle will now nominate a new candidate for ratification. They could choose Bob Lee as the runner up in the open vote.

Turnout

One key issue not previously mentioned is turnout.

Of 1286 registered voters, only 18% actually voted - about 232 people/companies.

In 2007 turnout was 33%, in 2008 it was 26%, in 2009 it was 21%.

So, less than 250 people/companies (JCP members can be either) actually voted on the organisation that holds the power to decide the future of Java. With up to 10 million Java developers out there, this really is a tiny number. In fact, more people voted in the latest Java.net poll.

While I'm sure the legal paperwork of membership puts any off joining, the truth is that even those that had joined failed to vote. Of course we will never know why.

Commentary

These were controversial elections, partly because of the upcoming Java SE 7 vote, partly because the JCP was described as "no longer a credible specification and standards body" by Doug Lea and partly because I saw signs of Oracle sharp practice.

In the end, my interpretation of "stacking the election" was addressed by Adam Messinger of Oracle:

On the topic of Hologic, our feeling is that standards folks, technologists, and technology vendors are already well represented and there is room for some new opinions at the table. The fact is that a big part of Java's success is driven by thousands of developers at small and mid-size companies like Hologic. These developers, who are working squarely in the Microsoft sweet spot, are on the forefront of our competition with .NET. Hologic has bet their business on Java -- not as a supplier of Java, but as a consumer -- and we think having their perspective on the EC is valuable. They are absolutely representative of a large cross section of the Java community.

So, did I call Hologic right or wrong?

When I saw Hologic's name on the ratification ballot my first response was surprise. Then suspicion. Why had a company that no-one had heard of been put up to be one of the core guardians of Java SE, EE and the community?

Given the importance of the JCP vote to come, and the surrounding controversy, I wanted to know more. It wsn't hard to find the close relationship between Hologic and Oracle. And I called it as I saw it.

Adam's explanation in terms of broadening the JCP EC representation away from technology companies is sound enough. However I would have to ask what would make any one company, like Hologic, any more or less relevant than another? Ultimately, the electors agreed that Hologic should not be on the JCP EC, although we cannot know how much of that was due to the closeness to Oracle (that I pointed out) and how much was due to a general concern that they simply were an inappropriate company to be on the JCP EC.

The net effect of this is a sense that technology companies are better placed to provide the detailed technical direction needed for Java.

But that analysis also calls into question the role of Credit Suisse and individuals.

I think the difference with Credit Suisse is that they are a known company and are presumed to have a significant hard core Java operation (most banks push Java to the limit in places). And good individuals provide a key role in balancing the political nature of companies (which is why it was sad to see Doug Lea go and Bob Lee not to be elected).

For the future, it looks as though the Java SE 7 vote will pass. With the inability to get a valid testing suite for Apache Harmony finally confirmed, there may yet be further changes in the JCP. Fundamentally, it can reform (as per my #splitjcp compromise proposal or another similar proposal), or continue to be seen as irrelevant by many like me.

Either way, there needs to be more engagement of the wider community of developers beyond the apathetic JCP membership. If the most contested and discussed election in JCP history cannot increase the turnout, then maybe root and branch changes really are needed - and might in fact be welcomed.

Summary

Less than 250 JCP members (18% turnout) have made their choices, deciding the fate of Java. Apache, Red Hat, Google and Eclipse were elected. Hologic and Bob Lee were not.

Is this the best way to receive community feedback? Somehow it doesn't feel like it. Once again I'm encouraged to push for radical JCP reform.

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