I have a few questions and comments about the IGB meeting on the TCK...
Mark Reinhold wrote:
> 2 License eligibility
> Q5: What about hybrid implementations, for example what the Cacao folks
> are working on, where they're using the OpenJDK class libraries on
> top of their own VM to run on PowerPC or S/390 machines? Would they
> be eligible for the TCK license?
> The Classpath library running with the HotSpot VM would certainly count as
> substantially derived, since the HotSpot VM is a significant chunk of code.
It doesn't make sense to me that both of these would be considered
a) Your own VM with OpenJDK libraries
b) Your own libraries with the OpenJDK VM
That seems to me like saying that both of these are "derived" from a Honda:
a) A Honda engine in a non-Honda car
b) A non-Honda engine in a Honda car
What's to stop, say, Apache Harmony, from releasing three versions:
1) A GPL2 version, tested with TCK, consisting of Harmony libraries and
2) A GPL2 version, tested with TCK, consisting of Harmony VM and OpenJDK
3) Their current product, Apache license, not tested with TCK, but
consisting of the *same code* that
has been tested with the TCK
Also, the explanations given just don't seem to match up with a
reasonable definition of
"substantially derived". Rather, they're just talking about
(VM and libraries) of a whole. I think neither a Honda engine in a
nor a Honda car with some other engine is "substantially derived" from
an original Honda.
The engine is just too big of a part of the car, and a VM is too big a
part of a JDK.
And I think there's just no "deriving" going on here anyway. "Deriving"
would be to modify something
from the original, not mix-and-match parts.
> because the OpenJDK TCK
> license requires that a tested implementation be released under the same
> license as the OpenJDK code itself, which at the moment is GPL version 2
I don't see how you can decide whether some release qualifies based on
what might be done with it
in the future (more below).
> Q8: Would the Harmony class libraries combined with the HotSpot VM be
> considered "substantially derived?"
> In terms of the code, yes, this combination would be considered to be
> substantially derived.
> To be eligible for the OpenJDK TCK License, however, you'd have to be
> planning to release the whole combination under GPLv2, and that's likely a
> problem. Neither Apache, the FSF, nor Sun view the Apache license as
> compatible with GPLv2, at least not if you're incorporating Apache code
> as-is. You'd have to decide for yourself whether such a combination is
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? What if Apache says they are "planning" a GPL2 release, but
you don't believe them?
> Q13: Does an implementation have to pass every single test?
> Yes, every single valid test in the suite must pass. You can challenge the
> validity of specific tests, however, and sometimes tests are thrown out as a
> result of such challenges.
How will this challenge process work? For example, the "spec" (javadoc)
for the DateFormat.equals() says something
so vague that virtually anything should pass the test. Assuming that the
test actually tests something,
and assuming that some implementation fails, what happens? Does "thrown
out" mean the test is actually
removed from the suite, or is the test case fixed to match the spec? If
the test case is fixed, is the
implementation considered to have passed in the meantime? If it's the
spec that's to be fixed (which could
take a very long time), what's the status of the implementation in the
> Q14: What's the difference between passing the test suite and actually
> certifying an implementation as compatible?
> That's an important distinction. A compatible implementation must meet all
> the requirements that are spelled out in the TCK User's Guide, specifically
> those in Chapter 2. It must not only pass the test suite but also satisfy a
> set of rules that are, inherently, untestable. In other words, there are
> parts of the certification process that amount to you asserting that, to the
> best of your knowledge, you're not breaking compatibility. It doesn't mean
> that you don't have any bugs, it just means that you're not knowingly
> violating any of the relevant specifications and other requirements.
Is there a way to find out what the TCK User's Guide says before
actually licensing it?
The reason I ask is that its wording here is crucial. Historically, C
and C++ implementors have worked hard for years on
standards to ensure that they're not "breaking compatibility", and yet
one of the major advantages of
Java is WORA - that it's compatible across platforms and
implementations, while C and C++ are not.
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?
One good example here is keywords. Both the C/C++ standards and the JLS
specify a list of valid
keywords. But they do not say "...and these are the only keywords". This
was a key issue in the MS
trial, where MS added their own keywords.
Isn't it reasonable for the general Java developer community to know
what this TCK User's Guide says?
For example, I wouldn't dare try another implementation unless I know
that the other implementation
has no additional keywords. The TCK User's Guide may ensure reasonable
compatibility, but if only
licencees can read it, very few people will care.
Suppose an implementation feels that they do comply with the TCK User's
Guide wording, but
Sun disagrees. Then what? Or suppose an implementation feels that the
wording should be changed?
Than what? Does an implementation have any way to appeal Sun's decision?
> Now the practical reality, of course, is that there will be modes that don't
> pass, e.g., modes that just print a version string and exit, or that provide
> certain kinds of debugging information. The rules cover all these sorts of
> special cases and exceptions.
I don't see how it's possible to have wording that allows things like
"debug mode", where arbitrary trace info is printed,
but disallows "fast mode" where array bounds checking is skipped. I
guess I'll have to take your word for it,
if I can't see the TCK User's Guide.
> The expectation is that people are acting in good faith, trying to meet the
> compatibility requirements, and that they aren't knowingly doing something
> that would violate them. They're expected to make their own choices around
> risk, with the understanding that if a mistake is made and an implementation
> isn't compatible then Sun could ask them to stop claiming it's compatible and
> stop using the Java logo with it.
Sun should know better than to assume that it's as simple as expecting
people to be acting in good faith.
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.
Also, some say that the Netscape implementation was less compatible than
the Microsoft implementation
at the time that Sun sued Microsoft for being incompatible. Most Java
developers think that was the
right decision, and it was a decision that certainly did not expect that
everyone was acting in good faith.
And Apache may be acting "in good faith" when it comes to compatibility,
but not so much when it comes
to releasing under a GPL-compatible license.
> This is pretty much how Sun has worked with its commercial licensees for many
> years now. This should scale to the relatively modest expected number of new
> OpenJDK TCK licensees that will want to self-certify and carry the brand.
Of course, there's the problem that an implementation may start out
compatible, become dominant, and
HTML, CSS, and other languages.
> Q19: If an OpenJDK-derived implementation is still in beta, or is
> declared final but isn't compatible, can it still be shipped?
> Yes. This is a key difference between the OpenJDK TCK license and the
> traditional TCK license available under commercial terms from Sun.
> Under the commercial license an implementor can ship early-access or beta
> releases and not worry about compatibility, so long as they don't claim
> compatibility and don't allow production use. Once they're ready to ship the
> final release to customers and support it in production, however, then it
> must be compatible -- otherwise they can't ship it.
Well, anyone can ship anything they want, they just can't claim that
it's "Java compatible", right?
And in practice, they could even do that, and it would be up to Sun to
take them to court to stop them.
> 5 Confidentiality
> Q21: What about the confidentiality clause in the OpenJDK TCK license?
> Does it allow for the publication of test results? That is, can
> one talk about what passes and fails in public?
> Yes. Sharing the results of test runs is fine, per section 5.1 of the
> license. You can say things like "I passed all the tests," or "I passed all
> the VM tests, but failed these seven compiler tests," or you could even, if
> you really wanted to, publish the entire log of a TCK run.
> Sun doesn't, however, want people to make comparative claims of
> compatibility, e.g., "I'm just as compatible as that other guy over there,
> but not really actually compatible," since that will tend to confuse people
> about what compatibility means.
I assume that when you talk about what "Sun wants" here, you actually
mean that the license has wording
to enforce what "Sun wants". Yes?
> The confidentiality clause is intended to protect the tests themselves, not
> the results of running the tests. You can't disclose the details of the
> tests publicly, though you can discuss them with other parties who've also
> signed the OpenJDK TCK license.
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?
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?
> Finally there are functional, performance, and reliability test suites. Some
> of these will likely be open-sourced over time although some cannot, again
> due to legal constraints.
Suppose an implementation is compatible, but very unreliable. Is there
any provision in the TCK (or
elsewhere) where Sun can attempt to stop the use of the Java trademark
in that case where Sun just
wants to protect the integrity of the brand?
Thanks for making all these discussions so open.
I hope you find these comments useful and not just paranoid ranting.
Enough people have struggled with incompatible compilers for decades to
justify some paranoia.