OpenJDK GB Minutes: 2007/8/23

[Mark Wielaard]

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