There is so much going on with the transition of Java EE from Oracle to the Eclipse Foundation, that it can make your head spin. Java EE is a huge platform, not only in terms of technology, but also in terms of specifications, governance, and marketing. This “Unofficial” state-of-the-union is an attempt to bring people, not intimately familiar with the work being done, up to speed.
Obviously, this is subject to change as the transfer of intellectual property from Oracle to Eclipse Foundation, the establishment of a governance model, and the marketing plan are still being defined. Hopefully, however, this series of articles will provide you with a solid understanding of everything currently being done within the Jakarta EE Working Group.
This article is being delivered as a three-part series because there is so much to be discussed that addressing it all at once would be challenging to write and read. This first installment, Part I, addresses the issues and challenges with the transfer of the intellectual property associated with the Java EE platform to the Eclipse Foundation and the formation of Jakarta EE.
Transfer of Intellectual Property: What is being donated?
In the Fall of 2017 Oracle announced that it would be donating Java EE to the Eclipse Foundation. Everyone knows that, but what does that mean? It means that Oracle will work with the Eclipse Foundation and its Members to contribute a variety of intellectual property associated with the Java EE brand including source code, JavaDocs, and Technology Compatibility Kits. That’s not something that happens overnight because it requires a lot of lawyers reviewing documents, communicating, and reaching agreements on dozens of points of law. It’s an inherently slow process and watching it take place can be akin to watching the water come to a boil, but it’s necessary to ensure that everyone and every organization involved is protected from intellectual property infringement.
The Java EE Brand
Perhaps the most obvious piece of IP to be addressed was the brand name, Java™ EE. As much as we would have loved to simply keep the Java™ EE brand name, Oracle was unable to donate it to the Eclipse Foundation, so a new brand name had to be selected. By now, you know that the new brand name is Jakarta EE, which is in the process of being trademarked by the Eclipse Foundation and is becoming common in the parlance of the industry as a whole.
The selection of the name was done, as best as could be, in a democratic manner with the entire community suggesting names, the Eclipse Foundation reviewing the trademarkability of those names, and then the community voting on the best of two remaining options. I think the outcome is excellent. Jakarta EE is a brand name that most people can get behind. And while that took some time and effort, it was the least difficult bit of IP that needed to be worked out.
Glassfish and the Java EE Reference Implementations
Another piece of the IP puzzle was the donation of the Java EE reference implementations to Eclipse. Glassfish 5.0 is a Java EE 8 compliant application server that was developed by Oracle and donated to the Eclipse Foundation. Glassfish has hundreds of moving parts and several sub-projects all of which have many contributors. The process of moving all these open source projects has taken a lot of effort and is still ongoing, but progress has been made and new projects under the Eclipse Foundation are being launched fairly regularly. In the end, a great deal of the code that made up the Java EE reference implementation will be under the guidance of the Eclipse Foundation and managed within the Eclipse Enterprise for Java (EE4J) top-level project.
The javax Packages, JSR Specifications, and TCKs
The Java EE standards were defined by the JCP in a collection of JSRs. Most of the JSRs delivered a written specification document, as well as, a Java API in the form of a set of packages under the javax namespace. The Java APIs usually define a vendor agnostic interface that is then implemented by vendors and open source projects, as well as, a specification document that described the expected behavior of software implementing that API. In addition to the Java APIs and Specifications, each JSR required a Technology Compatibility Kit used by Oracle to certify that vendor and open source implementations actually conformed to the specifications and APIs.
The javax Namespace
The javax packages, which define the vendor agnostic API of Java EE, have been used for years (e.g. javax.jms, javax.ejb, javax.servlet) will now be maintained by the Jakarta EE specification process at the Eclipse Foundation. This donation has its own IP headaches and limitations.
While Oracle was able to donate the javax.* packages, they were not able to give the Eclipse Foundation full derivative rights. The result: The Eclipse community can add new classes and sub-packages to existing javax.* packages, but it cannot create entirely new packages using the javax namespace. Why? The name javax is trademarked by Oracle and was not donated to the Eclipse Foundation. It was donated with a limited license, so any new top-level packages defined for future versions of Jakarta EE will have to use some other namespace. One possibility is to use jakarta as the new namespace for future packages.
The Specification Documents
The specifications for all the technologies used in Java EE are critical to defining compliance across Java EE implementations. The specifications not only define the expected behaviors of the APIs, but also critical cross-cutting concerns like the impact of transactions, means of configuration and packaging.
Unfortunately, Oracle was not able to donate all of the Java EE 8 specification documents (e.g. JMS, EJB, Servlet) because these specifications were developed under the Java Community Process and included the efforts of hundreds of people, many of who are not Oracle employees. The end result is that there is a great deal of intellectual property in the specifications both in terms of raw copyright text but also in terms of patented ideas. In order to donate the specifications, all the IP associated with each specification would need to be reassigned with the permissions of every organization or individual involved. Not only would that be a huge undertaking, it’s essentially impossible for many specifications because there is no record of who exactly contributed what.
Faced with the fact that most of the specifications themselves cannot be donated, the Jakarta EE community will have to redefine every standardized technology in Jakarta EE with new specifications contributed by Eclipse members under an entirely new, Eclipse defined, contributor agreement. Whether, or not, these new specifications can reference the originals and then stipulate changes or, if they have been re-written from scratch, is still unclear.
Technology Compatibility Tests
When a vendor or open source project wants to certify that their implementation is Java EE complaint, they have to run their implementation in a test harness, the Technology Compatibility Kit (TCK). The TCK puts the implementation through a bunch of hoops to ensure solutions are implementing the APIs correctly and behaving as prescribed by the JSR specifications. For the past 20 years, these TCK tests were confidential, proprietary and could only be used by paying Oracle a fee. An exception was made for open source projects, but for smaller companies, the costs were often prohibitive. Once paid, Oracle would deliver the TCKs to the vendor – with a strict non-disclosure agreement – and the vendor would run the tests reporting the results (pass or fail) back to Oracle. When a vendor’s implementation passed, they were certified.
The code that makes up the TCKs was a black box for vendors and only accessible by paying Oracle’s required fees, but now, all the code that makes up the TCKs, and there is a lot of it, is in the process of being donated to the EE4J project and will become open source. This code base will be part of the foundation of defining Jakarta EE compliance in the future and its development will be, for the first time, done in the open with the source available for anyone to download and examine. This is a huge change for the community as it helps to even the playing field among vendors and will ensure that future TCKs are not only open but subject to community scrutiny. As a result, it will be easier for the community to spot gaps in the TCK tests, which, would ordinarily lead to incompatibility problems across implementations, and close those gaps to create a far more portable platform than at any other time in the past 20 years.
Special thanks to Mike Milinkovich of Eclipse Foundation (@mmilinkov) and Bill Shannon of Oracle for reviewing an early draft and providing invaluable feedback before publishing.
Next, Governance
While the transfer of intellectual property from Oracle to Eclipse Foundation has many challenges the work is proceeding well, but it’s not the only thing the Jakarta EE working group is focused on. In addition, there is much work to be done in terms of defining how all this is going to be managed and that is the subject of the next installment, Part II, of this series, which, I hope to publish next week or the week after.
