Hi Andy, Saw some comments on GNU Classpath in here, so I thought I should clarify those points for you.
Although I should probably preface it with saying that I think the proprietary TCK is not very interesting to me personally. I like the fact that people can now get access to the TCK to verify compatibility claims and still release their software under a free license like the GPL. That is a huge improvement over the old state. But in the long run we will have to find a way to have the TCK itself as Free Software so it can be included with any free JDK implementation and distributions, developers and users can make sure it is always run for their particular environment. Only that will imho really solve the compatibility claims issues. On Fri, 2007-12-07 at 13:05 -0500, Andy Tripp wrote: > What's to stop, say, Apache Harmony, from releasing three versions: > 1) A GPL2 version, tested with TCK, consisting of Harmony libraries and > Hotspot > 2) A GPL2 version, tested with TCK, consisting of Harmony VM and OpenJDK > libraries > 3) Their current product, Apache license, not tested with TCK, but > consisting of the *same code* that > has been tested with the TCK Nothing as far as I can see as long as they solve the GPL/ASL license compatibility issue (hopefully openjdk and classpath will move to GPLv3 soon to make this a non-issue). This is analogous to the situation with GNU Classpath, gcj, cacao or icedtea, there will still be the source code released versions under the GPL even if people might have tested and certified a specific binary release against the TCK (note that GNU Classpath for example only releases source code). > Again, how can you decide based on what someone is "planning" to do in > the future? What if, > say, Classpath says they're "planning" a future release under GPL2, but > then never actually > release it? You have to trust us :) You can already get the GPLv2 version of GNU Classpath, we have already released multiple versions under that. And I can safely say that we are planning to release a version of GNU Classpath under GPLv3 (+ exception) one day. But that we will most likely wait till OpenJDK also moves to GPLv3 to make collaboration between the projects easier. > For example, the "spec" (javadoc) > for the DateFormat.equals() says something > so vague that virtually anything should pass the test. With software it is not just about the "spec". And I don't think anybody would really claim that the javadoc is a very good spec. Luckily there are other sources of information, like in this case The Java Class Libraries, second Edition, Volume 1 book which has an extensive explanation about the behavior of DateFormat, 30 pages, including a proper description of the equals method. And the final judge is as always real applications. If there is code out there, preferably free software, that show what applications expect then that is what you should test and implement. That is what real compatibility is about. > So how can someone like me, who wants Java to succeed but has not built > my own implementation, > figure out whether this is just "the C/C++ standards process all over > again" or something better? See above. Test your applications against an implementation. And lobby for a proper free testsuite (or contribute to one like Mauve) so all end users can make sure for themselves how compatible it is and how good the coverage of the suite is. > For example, there was a discussion on the Classpath mailing list a > while back about what the various > toString() methods should print. There's nothing in the "spec" (Javadoc) > covering this, and people naturally > wondered "should I print what I think is reasonable, or do I have to go > through lots of work to figure out > exactly what Sun's implementation prints and match that > character-for-character?" These people are > clearly working in good faith, but it's completely unreasonable to > expect them to have full compatibility. > IIRC, it was left up to each developer. The rule for GNU Classpath is to have at least as good and meaningful toString() results as other implementations. Of course every developer is encouraged to strive for excellence and make sure the descriptions are even more useful to end users than in other implementations if nothing is specified. The overriding restricting is that if real world, free software, applications depends on a particular toString() format, even if not specified, then we will fix the classpath implementation to make more applications work. > If a licensee can't disclose the details of tests publicly, how will > that work? Say Classpath has a license. > Does that mean that Classpath developers can't say "...the TCK checks > for such-and-such here, could > someone fix that?" on their public mailing list? As far as I know people are allowed to say that as long as they don't directly disclose the TCK source code for such tests. What will happen in practice is probably that people will be asked to write a free test for a free testsuite like Mauve before such an issue is fixed so that all developers can have access to the expected behavior and no regressions slip in. > And who is even considered "a Classpath developer", and > so is allowed to see the TCK, considering that to become "a Classpath > developer", you just need > to go ahead and contribute? GNU Classpath as project doesn't make any proprietary NDA agreements, that would be outside the charter of the FSF, who is the guardian of the project. It wouldn't be in the public interest if there was some secret cabal of classpath developers "in the know" and others not. So it is up to individuals to decide whether or not they sign the TCK agreement. Since signing it doesn't prevent you from contributing to GNU Classpath and releasing the code under the GPL anyone can do that. Whether the inconvenience of signing an NDA and not be able to discuss it with your peers is worth it is up to each individual. Cheers, Mark
