Fri Nov 28 14:43:00 GMT 2003
Stephen Crawley wrote:
> firstname.lastname@example.org said:
>>A mauve test attached. Since I have got a write access to the mauve
>>CVS registry, I will add it to the registry. The test results shows
>>that Sun's implementation also seems to have something wrong.
> If Sun's implementation (you don't say which JDK version!) is failing
> a test, then that casts serious doubt on the correctness of the mauve
> testcase itself!
Sure. On the other hand, it also casts doubts on the quality of Sun's
implementation. The JDK is quite buggy, see the JDK Bug Parade for a
reference. The implementations are often less buggy that what we have in
GNU Classpath or kaffe at the moment, but they are far from perfect, in
my experience. I don't usually have much trouble crashing Sun's 1.4.2 VM
with my java code. ;)
After looking at the test case, I'd say that it excercises a bit of a
very badly specified area of the JDK. java.util.Calendar has a very,
very ugly API. You can set the fields separately, but setting them can
trigger recalculations & clearing of other, related fields.
Unfortunately, how the changes propagate is not very well documented,
unless you shelve out the cash for the Java Class Libraries Vol. 1, 2nd
Edition & and the Vol. 1, 2nd Edition Supplement books. Even then, it's
not very clear that if setting HOUR first (which triggers an update of
AM_PM) and then set AM_PM (which triggers an update of HOUR) has the
same effect as setting AM_PM first and then setting HOUR.
I've tried Ito's test case with the setting of AM_PM and HOUR in
reverse. The results for the JDK 1.4.2 are the same, it still breaks on
the same four test cases as before. Clearing the calender to avoid side
effects in field computation because of current time's fields being set
doesn't help, either.
Bascially, there seems to be no way to tell Sun's JDK that you want to
have 12:[00-59] [AM|PM] by using the set(field, value) API.  Which
looks like a bug in Sun's implemenation to me, and this test exposes it.
> The over-arching principle for Mauve testcases is that the behavior of
> Sun's Java implementations is the "gold standard" for conformance
> testing. Even if the Sun Java behavior contradicts the javadocs, or
> is "just plain wrong", it is still technically "correct behavior" from
> the POV of conformance.
That depends on the situation. If the behaviour is clearly a bug, like
in the above case, I'd say report it to Sun, make sure Classpath does it
better, and have a mauve test to expose the bug in the JDK.
After all, the goal shouldn't be to just have the classes, it should be
to have the superior implementation. Having a test suite of our own
helps in showing that everyone's implementations are buggy, but at least
you can fix the free ones and share the fixes ;)
> [Sun sometimes acknowledges JDK bugs, but then says they won't fix them.
> because of the risk of breaking existing customer code. In such cases,
> other Java implementations need to be bug-for-bug compatible in order
> to minimize cross-platform portability problems for developers and
Yes, but they also fix a lot of bugs between releases, judging by their
release notes. If the software depends on the bug, I'd say fix the
software ;) If the software depends on some badly specified part of the
spec, I'd say write tests & make sure we understand that part well, so
that we can make Classpath's code even better than the JDK. Which is the
case here, I believe.
In the long run, the JDK is as irrelevant as an industry standard as SCO
Unix is now. Ten years ago, there were many (closed source)
implementations of Unix-ish OSes. GNU/Linux is gradually replacing them.
I boldly predict that the same will happen with Java. True WORA for Java
will arrive, but it will arrive through free software efforts like mauve
& GNU Classpath  that will provide the next reference platform.
 Unless you can somehow guess that setting AM_PM seems to wrap the
clock time around in a rather weird way, so that when it's 12 and you
set it to PM, you get AM, but when it's 12 and you set it to PM, you get
 And kaffe, gcj, sablevm, kissme, etc. of course ;)
More information about the Java-patches