After an undeniably rocky start, which saw high profile resignations from the JCP, including Doug Lea (who remains active in the OpenJDK), and the Apache Software Foundation, Oracle is making significant efforts to re-engage with the wider Java ecosystem, a theme which it talked up at the most recent JavaOne conference. The company is working hard to engage with the Java User Group leaders and Java Champions, membership of the OpenJDK project is growing, and the company is making efforts to reform the Java Community Process to improve transparency. The firm has also published a clear, well-defined Java roadmap toward Java 8 and Java 9. Problems still exist however.
JCP.next: Reforming the Java Community Process
The Java Community Process, through a series of initiatives lead by chairman Patrick Curran, is aiming to improve its transparency and agility. JSR 348, which is the first in a series of reforms Oracle plans for the JCP, has passed final approval ballot. It represents relatively minor changes, but it is still an important step, requiring that in the future all Expert Groups conduct all of their business in public, using a public mailing-list and a public issue-tracker. Java.net will be used to provide the core infrastructure. Curran told us
I ran JSR 348 as a java.net project, and this worked very well - everything we needed was there. I expect that many Spec Leads (and probably all Oracle Spec Leads) will similarly rely on java.net.
Similar rules are also applied to the Executive Committee, which already publishes all of its minutes and meeting material, but will now be required to hold at least one public face-to-face meeting, which will typically be held at JavaOne according to Curran, and two public teleconferences. The EC is also required to create a public mailing list for community feedback. The EC is still able to go into private session. Curran told us
I think this is an option that the EC should retain, but that it should be exercised very rarely (as indeed it is). The last time we went into private session was in September 2010, when we discussed announcements that were planned for JavaOne, but that we wanted to keep confidential until after the event.
In addition, JSR 348 requires that any requests to join Expert Groups will be published, and defines formal processes for dealing with situations where Expert Group members or Spec Leads are not performing their duties, as well as penalties for Executive Committee members who do not attend meetings. From the EC Standing Rules document (PDF)
- Missing two meetings in a row (whether teleconference or face-to-face meetings) results in the loss of voting privileges in all JSR ballots and EC votes that have not yet started. An EC member who has lost voting privileges cannot make or second a motion. Privileges are regained after full attendance at two consecutive meetings.
- Missing five meetings in a row, or missing more than two-thirds of all meetings in any consecutive twelve-month period, results in loss of EC membership.
- The PMO shall provide regular attendance reports to the EC, and shall issue warnings to those who are at risk of losing membership.
- Under exceptional circumstances, to be determined on a case-by-case basis, the EC may waive either of the above penalties.
Finally 348 introduces time-outs for JSRs, such that they have to reach various stages in the process within a defined time limit or face being shut down. From the Java Community Process, version 2.8 document
If a JSR does not begin Early Draft Review within 9 months of completing its JSR Approval Ballot, or does not begin Public Review within 12 months of first submitting an Early Draft, or does not reach Final Release within 12 months of commencing Public Review, then the EC should initiate a JSR Renewal Ballot unless it is agreed that there are extraordinary circumstances that justify the delay.
Beyond this, Oracle is planning two additional JSRs. The first will look to combine to two JCP Executive Committees. Currently Java ME is represented by one Executive Committee, and Java SE and EE by a second, a position which makes little sense given Oracle's stated intent to combine Java SE and ME. This change should make the whole process more efficient, and may also help to promote more synergy between the different parts of the Java ecosystem.
The second JSR will be rather more involved, since it will look at the complex issues around IP and licensing rights, which were at the heart of the dispute between Sun Microsystems and the Apache Software Foundation, and which ultimately resulted in Apache leaving the JCP. Curran told us
As we worked on JSR 348 we created a list of items that were considered out of scope for that JSR. This will be used as a starting-point for our discussions on the follow-on JSR, but of course we haven't yet decided which of them to actually address.
One area of potential conflict is the licensing terms that the spec leads use for the TCK, which are controlled by the JCP participation agreement, generally referred to as the JSPA (PDF document). The JSPA governs IP issues and mandates fair access to the TCK and contains the RAND language. InfoQ had understood that spec leads could choose to charge for the TCK, though Curran told us that this wasn't entirely correct
Implementers of JCP specifications have a choice. They can create Independent (clean-room) implementations on Royalty Free terms, or if they wish to incorporate elements from the Reference Implementation in source or binary form they can license the necessary rights on RAND (Reasonable And Non-Discriminatory) terms, which must be disclosed in advance. Note that in either case the implementer must license the TCK in order to prove that the implementation is compatible. RAND licensing terms (disclosed in advance) may also apply here.
It is encouraging to see Oracle tackling some of the problems in the JCP, and there are other promising signs. At JavaOne, Oracle noted that there were five new candidates for the open vote to the Executive Committee this year - Azul, CloudBees (though it should perhaps be noted that Steve Harris, formerly SVP of Oracle and a long-term member of the JCP, recently moved to CloudBees as SVP of Products), Terracotta, Twitter and the Central Ohio Java Users Group. In the end, a total of nine candidates stood in the election, the strongest field for some time, with Azul and Twitter the successful candidates. Some more analysis on the election can be found here. It is good to see Oracle encouraging the engagement of Java User Groups, in addition to ISVs, in the process.
The OpenJDK
The OpenJDK has seen a great deal of activity since Oracle took over the helm with a number of companies joining the project. New firms over the past year include Apple, Azul Systems, IBM, SAP and Twitter. The full list of participants is impressive.
Twitter is, perhaps, particularly noteworthy since it isn't an ISV, a point Donald Smith made recently on his blog
In my mind, there are three waves of participation in open source projects. First, it's usually initiated by an ISV and other ISVs in the same industry. If the project is very niche, or doesn't really flourish, that will be it. But if successful, and if the project is platform/infrastructure oriented, we should expect to see a second wave of participants that are largely software companies, but where the software license is not the product itself. Twitter would be a great example of this – Twitter is software, but the software license is not the product. Beyond that, if the project continues to be successful we should see a third phase of participation from non-software companies. Companies where the software is critical, but it's not largely the product. More consumer oriented organizations, where the software is a means to an end. I'm thinking of banks, insurance companies, auto makers, etc.
Of course, what's more interesting than who has signed up to join is what they might contribute. IBM announced at JavaOne 2011 that, amongst other things, it would be starting a project to work on Jigsaw/OSGi interoperability. Twitter's Chris Aniszczyk has stated that the firm plans to "contribute in the areas of performance and metrics gathering around garbage collection in the JVM", and Azul Systems' CTO Gil Tene told us that the firm will be looking to contribute improvements to the HotSpot VM itself, such as enhancements to locking and the thread model.
In terms of actually making contributions, that OpenJDK Community TCK License Agreement (hereafter OCTLA) is the key document, so it is perhaps surprising to find that the OCTLA for Java 7 was released over six months after Java 7 shipped (see here). Tene emphasized the importance of the TCK when we spoke to him for this article
We are excited about participating in and contributing to OpenJDK. It's great to see Oracle following through on their commitments to enable others to meaningfully participate in the OpenJDK project. Substantial contributions require rigorous compatibility testing, and Oracle's recent moves to make the OpenJDK TCKs available to several additional third parties is a critical and positive enabler for both OpenJDK and the Java Community Process as a whole.
Until the TCK and its accompanying license were made available, it is hard to see how external contributors could work on the platform, for a number of reasons. For one thing, without being able to regularly test and verify that changes of any size do not subtly break compatibility, development cycles become impractically elongated. In addition, even the smallest one line bug fix proposed and contributed by an individual community member would benefit from being tested against the full TCKs before being submitted, and before the project's committers have to consider it and waste precious resources evaluating it. Moreover TCKs are essential for maintaining compatibility: There is nothing inherent to the OpenJDK license terms that would prevent someone from shipping code that has not been verified against the TCK tests as a whole, risking fracture and fragmentation of the platform.
The Android-Shaped Elephant in the Room
Whilst Oracle is working hard to engage with developers, the firm's decision to sue Google over its use of Java for Android has caused a lot of ill will amongst that same group, regardless of the rights and wrongs of the actual lawsuit. Partly this reflects growing unease amongst Java developers about Java's relevance in the mobile space. Whilst Java ME was an early success story for Java, and is still shipped on a large number of phones, the rise of the current generation of smart-phones and tablets, led by Apple with the iPhone and iPad, largely consigned Java ME to irrelevance in the space. Nokia, a long-term supporter of Java ME, continues to have an interest, but has shifted its focus to Windows mobile. Likewise beleaguered BlackBerry manufacturer RIM, who is shifting away from Java ME to a new OS based on QNX with native C/C++ as the preferred development language. In this context Android becomes incredibly important for Java.
The OpenJDK Contribution Agreement (OCA) is an interesting document in this context. It defines some obvious things, such as clarifying GPL rights and asserting that the code contributed is not known to be problematic, but it also does something else: it allows Oracle to take the code into its commercial products, and outside of the realm of GPL, and use it for whatever purpose it wants (including sub-licensing it under non-GPL terms to commercial companies like IBM). Such a provision is far from unique: MySQL, well before it was acquired by Sun, worked in a similar fashion. It is also essential. Without it, Oracle would be forced to split the code, developing it only on the closed side and, if they wished to, contributing only downstream. Such a flow would make it practically impossible for any third party to contribute to OpenJDK, as the acceptance of such code into the project would necessarily fork it (along licensing lines) from Oracle's commercial work. Were that to happen OpenJDK would get left behind.
Perhaps more importantly, the OCA does not restrict the downstream use of OpenJDK code in any way. The only license that governs the OpenJDK code is GPLv2 + classpath. The only thing that the OCA is a gateway for is accepted contributions into the upstream OpenJDK project. If someone wants to develop OpenJDK code and maintain their code purely under GPL (without licensing that piece of code back to Oracle under the OCA), they are free to do so, and they can distribute it in any way they want, and even refer to it as "derived from the OpenJDK code base" or "based on the OpenJDK source code".
Signing the OCA does not prevent non-OCA-based development. The OCA is just a vehicle for making actual contributions to the OpenJDK project. It only applies to specific code explicitly contributed under the agreement, and does not preclude orthogonal development of pure GPL code that would not become upstream-integrated into OpenJDK. In other words, a community member could potentially decide to contribute, for instance, a bug fix, under the OCA whilst keeping other pieces, such as an academic project experimenting with large module changes and major surgery under pure GPL if they wish to do so. Those pieces would then never become part of the upstream OpenJDK unless contributed later.
In the context of Oracle's dispute with Google over Android, there is a fairly widely held belief that Oracle does not allow people to use OpenJDK for embedded and mobile devices, wanting instead to collect licensing revenue from OEMs. Whilst Sun (and presumably therefore now Oracle) did have a field of use restriction for commercial licenses to third parties, and indeed it was to a large extent how Java development was paid for, there is no such limitation in the OpenJDK code license. In other words, all Google would need to do would be to ship a version of Android based on OpenJDK, and keep it under a GPLv2 license. It's the insistence of Apache and Google on being able to build things outside of the GPLv2 envelope that is the point of contention, and the area around which "field of use" restrictions do come up: Oracle, and before them Sun, has consistently refused to license Java source code without a field of use restriction under open source licenses other than GPLv2 with the classpath exception. What Apache and Google want to do is take Java source code (and/or use the TCKs to test clean-roomed Java source code like the Harmony project) and provide it under an alternative license (like Apache V2, for example).
This was also IBM's position, until a major shift last year. It seems probable that Oracle and IBM reached some sort of long-term agreement on licensing the same OpenJDK code back to them without GPLv2 restrictions - something Oracle is allowed to do commercially under the OCA - although Oracle declined to comment when approached by InfoQ on this. Assuming we are correct, such an agreement would mean that IBM does not have to worry about GPL contamination in their commercial products: they and others contribute to OpenJDK in the open, let Oracle re-license the code via the OCA, and IBM then gains a license to what is essentially the same code commercially via what ever agreement they have for this purpose. Theoretically then, a similar accommodation could be reached with Google.
Conclusion
Whilst a theoretical accommodation could be reached with Google, Oracle's decision to pursue the search company over IP infringement in Android is fraught with risk. Much as Microsoft did with .NET when sued on similar grounds by Sun, Google could simply decide to drop support for Java from Android, moving instead to a language it owns and controls, such as Go, or more probably Dart, and thereby leaving Java without a credible mobile story. Moreover the decision to pursue Google, a company well regarded by many developers, has generated a lot of bad feeling.
With regards the JCP, JCP.next and JSPA it is noticeable that some of the more difficult, but most important, items are being put off until last. As we've seen, it is the interpretation of the RAND language contained in the JSPA, and the surrounding debate over how binding it is, that is core to the Apache/Oracle split. It is also of a wider concern to commercial and other open source projects. Now, whether or not Apache is entitled to a TCK that allows them to test Apache licensed code may be debatable: Oracle has not offered such access to the TCK to any other licensees, so it is at least not being discriminatory. The vendor can reasonably argue that, on the commercial side, all licensees accept a field-of-use limitation, and that on the open source side, licensees accept the requirement to only ship tested products under GPLv2, which ensures the products will remain in open source. What Apache wants does not fall under either category. However, wherever you stand on that particular debate, the fuzzy RAND language in the current JSPA is of great concern, especially with the Apache issue as a precedent, since it casts doubt and uncertainty about future access to the TCK in the minds of people who may want to get behind the platform (either commercially or in open source). If it is felt that TCK access can be shut off in some arbitrary way, that will ward off investment of time and effort. A clear message on TCK access and availability is critical for the JCP to remain credible.
Equally, the fact that participants have to build and maintain their own TCK test environment makes it difficult for individual contributors. It would be good to see a community-reachable OpenJDK test bench that would allow 3rd parties, who have signed the agreements and received the TCK license, to test their OpenJDK based code against the OpenJDK TCKs. Ideally this would also be made available much earlier in the process, long before the actual release (i.e. when the specification is completed and the code is in advanced Beta/Release candidate states), and maybe even have "draft" TCKs available whilst the release is being developed. We did ask Oracle if they had any plans for this, but did not receive a response.
There are, however, grounds for cautious optimism. Oracle worked hard at JavaOne to engage with Java champions and user group leaders, and the success of that at the conference was noticeable. The reforms to the JCP are much needed, and it is good to see them happening. Equally welcome are the signs that OpenJDK is starting to gain momentum. Perhaps most welcome of all though is the fact that, after a long period of hibernation, Java itself is moving forward again.
About the author
Charles Humble is CTO for PRPi Consulting with overall responsibility for the development of all the custom software used within the company, and the lead Java editor for InfoQ. He has worked in enterprise software for around 15 years as a developer, architect and development manager. He co-founded Conissaunce, a UK based enterprise computing consultancy focused on the retail and financial services industries, and remains a director of the firm. He spends as much time as he can with his young family, and writes music with twofish.Twitter: @charleshumble