Hi Mark,
Thanks for the responses.
I should also mention that I'm also not personally interested in
alternative Java implementations,
but I'm quite paranoid about any of them succeeding. I feel that having
multiple implementations,
even ones attempting to be compatible, is the core problem with C and
C++ today, and I'd
like to stay in my comfy little "one Java" world :)
Mark Wielaard wrote:
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).
I hope Sun is listening here. If Harmony (or any other clean-room
implementation) can do this then all the legal attempts
("substantially derived") to stop them from using the TCK effectively
have failed.
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.
You've been "planning to" deliver a 1.0 release for how many years now?
:)
I do trust that you want to be compatible, in the same sense that all C
vendors want to be compatible.
They want to be compatible in the sense that people trust them enough
to use their products,
but not necessarily compatible enough to avoid having to port to/from
their implementation.
Obviously, though, the question is for a Sun lawyer: "are you really
going to have a legal agreement
based on one someone states they are planning?" Heck, I'll state that
I'm planning my own
derivative of OpenJDK if it lets me see the TCK.
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.
Dalibor and I have argued about this extensively in the past. I say the
Javadoc is a "user's
reference", not a "spec". Very few people will trust Classpath to be
compatible just because
it complies with the Javadoc.
Again, I hope Sun is listening. Thinking that an implementation will be
compatible just because it
doesn't violate this "spec" is an even bigger mistake than thinking
that multiple C/C++ implementations
will be compatible just because they all conform to the "standard".
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.
Very few people have the time or inclination to test their app on other
implementations. In the
C/C++ world, that's called "porting", and is hated by (almost)
everyone. Again, to Sun: I hope
you know what you're doing when you encourage multiple implementations.
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.
And of course, that's the problem. You want "good", not "compatible".
That's the direction C
and C++ vendors have taken, each adding their own "good" (but
incompatible) features. Thus,
we have porting, and thus the emergence of Java with the promise of
WORA. I don't want
"good" features, I want perfect compatibility. That's why people prefer
gcc and that's why
people prefer Java.
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.
So you only want to be completely compatible if forced to. Nothing
wrong with that, I'd do
the same thing, and that's exactly where we are today with C/C++.
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.
I think it's quite a gray area, distinguishing between saying "The TCK
compares the day and month" vs.
"The TCK says day.equals(other.day) &&
month.equals(other.month)". Again, the point to Sun is...
what are you trying to accomplish here, and does your license really
accomplish it?
I suspect that this "no disclosing the TCK source code" will not be
effective in stopping anyone.
I've heard that companies will set up a group for situations like this:
one group reads the TCK
and writes down, in English, what it says. The other group never sees
the TCK itself, but writes
the code from the English description.
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.
OK, Thanks for the clarification. So no one will ever say "The TCK has
been licensed to
Classpath" - it would only be licensed to individuals.
Cheers,
Mark
Thanks again,
Andy
|
