This is the mail archive of the mailing list for the Java project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GregorianCalendar fixes

Hi Stephen,

Stephen Crawley wrote: 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

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.

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 ;)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]