Eduardo Pelegri-Llopart's Blog

JAX-RPC and JAXB now under the new JDL!

The JAXB and JAX-RPC projects at Java.Net develop the Reference Implementations for these specifications. The source code for these projects has, until now, only been available under JRL, the Java Research License. JRL is intended for research and internal prototyping and does not allow for modifications intended for deployments. This is a problem for those groups that want to do their own support, want to apply fixes without waiting for the changes at Java.Net, want to take the implementation into different directions, or just want a security blanket. It tooks us longer than I wished but we finally fixed this deficiency through an additional, brand-new, license, JDL, the Java Distribution License, and by providing new access to the associated TCKs.

The JDL allows modifications intended for deployment and commercial use. JDL is a much simpler license than some of its predecesors but it preserves the key JCP compatibility requirement centered on Specifications and Technology Compatibility Kits (TCKs). The version of the JDL that we are using in JAXB and in JAX-RPC includes the right to access the TCKs for these technologies. These TCKs are now also at Java.Net and can be used, free of cost, on the Reference Implementations and on artifacts derived from them to help test their compatibility.

The JAXB and JAX-RPC production-quality implementations are already used in products like the J2EE SDK and the different editions of Sun's Application Server, in the JWSDP, and in stable and weekly individual builds. The new JDL license and the availability of the TCKs will expand the applicability of these Java.Net implementations to those groups that feel they need to do their own - compatible! - modifications.

Comments

• My congratulations to you and others involved for a step in the right direction. It's good to see Sun gradually moving forward.

  
  Unfortunately, the JDL still has a some problems that prevent people like me from using the TCK it to create independant yet compatible implementations or to evaluate the quality of implementations. I'll run briefly through a few to point out areas that I consider improvement-worthy.

  1. The (ii) definition of 'Modification' in JDL covers all implementations of the specification, even if they are made in clean-room fashion, i.e. as new files, written from scratch. That's pretty nasty, in my opinion. Is there a particular reason why Sun wants or needs such patent-like protection for the specification?

  2. The source code distribution grant prohibts an implementation under an open source license, because such a license would violate 2.1.(i).a and 2.1.(i).b. One could interpret this as Sun not wanting to see open source implementations of industry standards, which would be quite strange for a company that's build on open source, in particular since the technology itself includes open source portions, according to 2.4.

  3. What sort of trade secrets are there in a TCK? From my experience with Mauve, a test suite is not exactly superb alien technology from the future. I can't find a single paper on citeseer that claims some scientific breakthrough made in a technology compatibility kit, so I'm wondering what it is that's worth so much non-disclosure protection.

  4. Would using the JAXB TCK on, say, Kaffe[1], violate 2.2.2.(v) ? On IBM's JRE? What exactly is a third-party product?

  cheers,
  dalibor topic

  Posted by: robilad on December 13, 2004 at 10:02 AM

• 
  IANAL, but, let me give it a try...

  JDL is a source license, not a spec license. The spec license already allows for clean-room implementations of the specs, and there are several open-source implementations of these technologies, at ASF and elsewhere. What we are doing with JDL is granting additional rights, above what is in JRL, to this particular code base.

  There are two main concerns around the use of TCKs that are reflected in this particular version (1.0) of the JDL. One is not to weaken the concept of compatibility; in particular a concern that people would say: I am almost compliant. Some of the restrictions on disclosures in this version of JDL try to address this issue. The other concern with TCKs is support and test challenges. Support is as usual, except that TCKs are relatively complicated to set up (that is a bug, not a feature) and the experience of the TCK support group is that the support cost is high. A test challenge is what happens when the TCK and the implementor disagree about who is interpreting the specification correctly; it may involve just the TCK writers but it can also involve the spec leads and/or the EG. Test challenges are quite expensive; I have been at the receiving end of a number of them.

  The combined result of suport and test challenge costs is that the general use of TCKs is relatively expensive on our end. You can buy TCK support and Sun has a scholarship program to pay for this for non-profit groups like ASF, but we wanted to provide access to a potentially much larger, and possibly for-profit, audience. So, what we did, this time around, was to at least solve the problem for the customers of the RI and derived works. Since the TCK is developed against the RI the TCK is much more likely going to run out-of-the-box and we can use the development team at Java.Net to deal with most of the TCK. Not the ideal solution but better than before.

  You ask about Kaffe. I am in the J2EE / XML / WS side of the house so I have never looked at them, so I am afraid, very much IANAL on this one, sorry.

  BTW, last night I added a few comments on JDL and JRL in a separate

  blog.
  

  Posted by: pelegri on December 13, 2004 at 12:52 PM

• Thanks for the quick reply, Eduardo!

  
  I whole-heartily agree that compatiblity to a published specification is very important. It is very important to clean-room projects like Kaffe or GNU Classpath as well, as otherwise we wouldn't be able to run some of the very nice free software written in Java. Incompatibility comes with a heavy penalty.

  
  Unfortunately, up till now we were not able to get access to a TCK under conditions that would allow us to continue working on an open source implementation. As that has apparently changed with J2SE5.0, I'm looking a bit closer at the various TCK distribution, access and licensing models applied by Sun to the various pieces of Java technology under their umbrella. I see an encouraging change for the better in JDL from SCSL or JRL, so my kudos to you for working on a change. It's still not a license that fixes all the issues of its parents, so I'd like to understand the reasoning behind the provisions a bit better.

  What strikes me as a bit weird, is that the JAXB spec license allows independant (even open source) implementations, but the JDL license, under which the TCK is distributed, apparently prohibts them. I may be misinterpreting the intentions of Sun's licensing division, as IANAL, either, but wouldn't it make sense to unbundle the TCK from the implementation and allow the independant open source implementations to use it for compliance testing as well, without having to switch to the JDL?

  It's the bunding of the TCK and the technology that strikes me as odd, really, as it apparently leads to the legitimate wish to protect Sun's IP invested in their JAXB implementation leaking over into the TCK license. I doubt there is much IP worth stringent protection in a test suite. :)

  I wouldn't want to see people claiming compliance to a specification when they are not fully compliant either. On the other hand, the TCK licensing terms are a bit odd, there, too, as they don't let third parties check compliance claims of JAXB vendors independently. The license only grants the right to check one's own implementation. I think allowing all interested parties non-discriminatory access to the TCK would solve the issue with potential frivolous compatiblity claims, as every vendor would be equally under public scrutiny.

  I've heard from others that the effort required to setup a project for the TCK is massive, would you be willing to share some first hand experiences? I've asked Calvin Austin about his experiences with J2SE5 testing, but I haven't heard back from him yet. If this is a too public forum, please don't hesitate to e-mail me, I'm robilad@kaffe.org.

  I can imagine that TCK challenges are quite expensive. I ocassionally find myself wondering 'what were they only thinking when they designed this underspecified APIs' in J2SE. The JDK doesn't do that well on Mauve, nor does Javac do too well on Jacks, either. Too bad the specificatons don't come with a 'Rationale' document ... :)

  I believe that the high test maintenance cost you're experiencing are an inherent failure of the current JCP, though. By mandating a single reference implementation, there is a high 'cross-talk' between the specification, the RI and the TCK. You don't get to shake out as many bugs in the specs as you could if you had several implementations attempting to implement a specification *before* a JSR is officially declared finished. So you get to experience all those problems later, after the release has been done, and the results are available to a larger population implementing the specs on their own. I'd assume that fixing errors in the specs is more expensive later, than earlier.

  As a way to solve that, I'd like to point to the W3C, who only let recommendations become official specs after there are at least two implementations of them. Please also take a look at how the W3C is handling test suites, compatibility and all that under very, very liberal terms, apparently without the high support cost on their side.

  I believe that there are bits and pieces in W3C's process that might be worth emulating in future JCP versions in order to increase the quality of Java technologies in general.

  One last question ... who do I ask about running the TCK for JAXB and JAX-RPC on Kaffe?

  cheers,
  dalibor topic

  Posted by: robilad on December 13, 2004 at 02:32 PM

• 
  re: but the JDL license, under which the TCK is distributed, apparently prohibts them - The bundling is not intrinsic. The TCKs may be available under different licenses, with different terms and conditions and our JDL is just one of these licenses, where we bundled access to the TCK with the right to commercial use of the source to simplify the story for most developers.

  
  IANAL, but I believe Sun made a commitment to provide reasonable, non-discriminatory access to the TCKs without having to license the RI code.

  re: effort ... to setup a project for the TCK is massive - I presume from your reference to Calvin that you mean J2SE. If so, I have heard the same. The problem is simpler for a point technology. I hope to have some time next week to try it on for JAXB and/or JAX-RPC and report back.

  re: mandating +1 implementations - I agree in principle: I was the spec lead for several JSP specs and I think the dominance of Tomcat was more of a disadvantage (to the spec) than an advantage. On the other hand, I have heard people advocating that requiring a RI is slowing down the JCP process, so there are tradeoffs, and I suspect requiring 1 is probably the ideal number. Regarding W3C, I am not a W3C expert, but my understanding is that there are very few formalized test suites, XSLT being an exception, and implementing the spec is not exactly the same as passing the TCK. BTW - IETF also has a similar requirement, but with an interop requirement added.

  re: running the TCK for JAXB and JAX-RPC on Kaffe? - do you mean testing the RIs for JAXB and JAX-RPC but using Kaffe instead of another JVM?

  Posted by: pelegri on December 13, 2004 at 04:45 PM

• re: IANAL, but I believe Sun made a commitment to provide reasonable, non-discriminatory access to the TCKs without having to license the RI code.

  
  Yeah, that's my impression (watching from outside the JCP, and Sun) as well, though I haven't seen it officially announced (or just missed it, I guess).

  I'm still a bit confused about how one would go about getting the TCK for JAXB or JAX-RPC if, for example, the GNU Classpath developers decided to implement JAXB bits as well, under terms that would allow us to distribute the resulting cleanroom impementation under an open source license (GPL+linking exception). JDL doesn't seem to allow that, JRL neither (same sort of clean-room contaminating provisions regarding Modifications and license propagation).

  In any case, I'm looking forward to hear your account on getting the TCKs set up.

  Yes, my inquiry was about testing the RIs using the TCK on Kaffe. Would the JDL allow that? Who would be allowed to do it?

  cheers,
  dalibor topic

  Posted by: robilad on December 13, 2004 at 08:33 PM

• 
  re: how one would go about getting the TCK... - You are right, the JDL does not help you for this application. What you want is the individual TCK. Send me mail (pelegri@sun.com) and I can get you pointed towards the right person.

  
  re: testing the RIs using the TCK on Kaffe - I have fired an internal query and will get back to you.
  

  Posted by: pelegri on December 14, 2004 at 01:39 PM

• thanks! Let's switch to e-mail, then ;)

  cheers,
  dalibor topic

  Posted by: robilad on December 14, 2004 at 07:39 PM

This work is licensed under a Creative Commons License.