Technology Compatibility Kit
Covered by the Java Community Process (JCP) both Java as a language and the various platforms on top (Java SE, Java EE, Java ME) are developed. Each JSR (Java Specification Request) includes an EG (Expert Group) a bunch of documents and of course a reference implementation (RI) and a corresponding TCK (Technology Compatibility Kit). The TCK can be executed against implementations and checks them for compliance with the specification. So it basically is the code equivalent of the specification document. Most TCKs consist of a bunch of test cases as well as a "test harness" which executes the tests. If there is a TCK per JSR it is safe to assume that there are at least as many TCKs available as we have active JSRs in the JCP. But that is only a theoretical thought. Practically there aren't. At least not publicly avaiable. Besides JBatch, CDI and Bean Validation I can't think of much more. And those are only part of the Java EE platform which has at least 28 specifications. The majority of TCKs unfortunately is under lock and key at Oracle. But why? The main reason for this is that the TCKs are also used as a tools for the platform certification. Successfully running a TCK against an implementation proves it's correctness and with that somehow it's compliance.
What does platform certification actually mean?
The platform compatibility is an excellent advert for products. The Java EE compatibility list is a Who-is-Who of the Java EE server market. If you're not on that list with your product you basically don't have a chance of being recognized. With Apache Tomcat being the only known exception to that rule. But what does it take to get the certification? For Java EE there is the Java EE Compatibility Test Suite (CTS) which probably consists of little more than the sum of the individual TCKs. Honestly I have not seen it. You have to become a licensee of Oracle to get access to it. And this is exactly where it is starting to become expensive. I do not know how expensive exactly but once you payed you can access the CTS through the Java Partner Engineering web site. There is only one alternative way of getting hands on the CTS. Going through the Compatibility Testing Scholarship Program which is a way for non-profit organizations and individuals to apply for a free-of-charge CTS. The requests are judged by a review board. There is a PDF out there which explains how this process exactly works. Beside the ASF various other organizations and individuals gained access to individual TCKs and CTS as of today. Now that you know about the basic program and certification it is easier to look at the details for the two Eclipse projects that has been granted a CTS Scholarship. I need to preface the following with a little disclaimer. I only can draw my conclusions from what is publicly known. I don't have any insights or further information on the reasons behind. It might be much simpler than what I came up with ...
EclipseLink - the JPA Reference Implementation
According to press release from early May Oracle demonstrates its "commitment to Java developers and the open source community" by granting access to two TCKs and related support services to the Eclipse Foundation. Time to start wondering. Wasn't EclipseLink the RI for JPA? What exactly are they doing if not building the TCK for JPA themselves, right? Why do they need a license?
EclipseLink has its roots in TopLink. Anyone who knows the history of TopLink knows that this is a relatively old product that belonged to WebGain before it has been acquired by Oracle. WebGain was a strong Eclipse supporter and even a member on the Board of Directors back in 2002. Only five years after its acquisition by Oracle TopLink was donated to the Eclipse Foundation and has been there ever since. EclipseLink is available under the EPL 1.0. The project itself does not contain the TCK. A difficult situation for a RI. Looking at the list of committers isn't really exciting. 30 people. And only one non-Oracle. Why do I believe that this team actually owns the TCK (Oracle internally) and even develops it? Strictly speaking, EclipseLink has a license that doesn't fit the TCK licensing rules. Granting the Scholarship license here simply corrects some legal issues in that constellation.
Virgo - the Java EE Web Profile Server
But for Virgo the granted license really makes a difference, right? Maybe. Virgo is the former Spring dm server which was donated to the Eclipse Foundation by SpringSource back in 2010. The list of committers paints a different picture than the TopLink list. It is not just SAP behind every name. Committers spread equally among three companies. SAP, Pivotal and Tasktop Technologies. The latter has an interesting management board. Former SpringSource COO Neelan Choksi and Rod Johnson himself are members. This might indicate that Pivotal has a little more influence on the project than SAP. Anyway, both companies are most likely not big Oracle buddies. The scholarship license isn't a gift for them obviously. In fact, Virgo is already Java EE 6 certified. However, under another name. The SAP NetWeaver Cloud has built its Java EE 6 Web Profile offering on Virgo. So SAP has probably acquired a license from Oracle and certified Virgo themselves. I don't know for sure but someone could have come up with the idea that it is cheaper to use an already certified server instead of paying the annual royalties year by year. Given the fact that the Eclipse Foundation is a non-profit organization it was easy to apply for the Scholarship program to get this sorted. At least in this case there is a positive side-effect. Virgo now has the chance of becoming another Java EE certified server. SAP already has proven that it is possible. Sooner of later the community will earn the profit by probably having a new EE 7 certified OSS server.
But it is a positive sum below the line, right?
Two new projects gained access to the TCK of the specification they are implementing. That is positive. Looking at the total sum of publicly available TCKs it is still frustrating. Especially in the EclipseLink case it is frustrating because the TCKs may not at all be available in public. An elongated discussion on the JPA mailing list from last year discuss this problem a bit and illustrates the drawbacks. Although it is getting better with the changes made by the JSR-348. We're still not there. In fact I expect that the TCKs are available to all interested parties. This would improve quality of the specifications and the reference implementations by finding holes in the specs and also inadequately tested areas of RIs. Both will prevent many errors from affecting users. As key part of JSR 358 is the work done towards a new licensing model for TCKs. An accompanying Java.net project contains all the discussion materials and is publicly accessible. Everyone is free to join the discussion and express his or her opinion. The Observer mailing list is available to any registered java.net user. If you're interested in the view of CloudBees, Red Hat and IBM onto licensing issues you can find some more material on the presentations page. Oracle itself proposes to proceed with standard TCK licensing models in the future version of the JCP:
"TCKs for all future JSRs must be made available for certification and branding purposes under one or more of the Approved Open Source Licenses and / or a Standard Commercial TCK License. The TCK for all future non-umbrella JSRs must be made available to all Participants in the relevant RI open source project under a standard JCP Community TCK License. " (Source: Oracle's Proposal for JSR 358, PDF, pages 15 +16)That would be a step in the right direction and would truly help the open source community. If the granted TCKs are a gift or not: It simply isn't enough to cure today's problems. We need a general change if it should be better in the future.
