Re: GregorianCalendar fixes

[Dalibor Topic]

Hi Stephen,

Stephen Crawley wrote:
> address@hidden 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. [1] 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
> end-users.]

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 [2] that will provide the next reference platform.

cheers,
dalibor topic

[1] 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 
AM.
[2] And kaffe, gcj, sablevm, kissme, etc. of course ;)