Re: GregorianCalendar fixes
Hi Ito,
after the discussion on the Classpath mailing list, I'd say it looks good ;)
Mark, can I check it into Classpath's CVS with an updated ChangeLog entry?
2003-11-29 Guilhem Lavaux [EMAIL PROTECTED]
* java/util/GregorianCalendar.java (computeTime):
12:00 midnight is AM and 12:00 noon is PM.
cheers,
dalibor topic
Ito Kazumitsu wrote:
Hi,
: == Mark Wielaard [EMAIL PROTECTED] writes:
: Looked some more at the code and I see now that the the first change was
: inside a if (time = gregorianCutover) so it now makes more sense to me.
: And the second change seems correct given the above remark.
: I'll commit it in Classpath.
There is another difference between GNU Classpath's
java/util/GregorianCalendar.java and that of kaffe.
Kaffe's was imported from GNU Classpath and modified
in the kaffe world, as described by the following
ChangeLog entry.
2003-08-16 Guilhem Lavaux [EMAIL PROTECTED]
* java/util/GregorianCalendar.java (computeTime):
12:00 midnight is AM and 12:00 noon is PM.
Here is the patch that can be applied to Revision 1.21:
--- java/util/GregorianCalendar.java.orig Thu Nov 27 15:35:08 2003
+++ java/util/GregorianCalendar.java Thu Nov 27 15:48:25 2003
@@ -402,7 +402,11 @@
{
hour = fields[HOUR];
if (isSet[AM_PM] fields[AM_PM] == PM)
- hour += 12;
+ if (hour != 12) /* not Noon */
+hour += 12;
+ /* Fix the problem of the status of 12:00 AM (midnight). */
+ if (isSet[AM_PM] fields[AM_PM] == AM hour == 12)
+ hour = 0;
}
int minute = isSet[MINUTE] ? fields[MINUTE] : 0;
___
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi, On Fri, 2003-11-28 at 04:39, Stephen Crawley wrote: Mark Wielaard [EMAIL PROTECTED] wrote: On Fri, 2003-11-28 at 02:03, Stephen Crawley wrote: The over-arching principle for Mauve testcases is that the behavior of Sun's Java implementations is the gold standard for conformance testing. I don't agree. We should not create Mauve tests to validate some proprietary library implementation. I don't understand what you are saying here. Sorry, was way past my bedtime. Maybe I should have taken more time explain. I was mainly disturbed by the suggestion that some proprietary implementation should be pointed out as the gold standard and that if that same implementation decides not to fix bugs then it isn't a bug. There are lots of examples of bugs in some widely used implementations. Mauve points those out. For example floating point string representation, or solving the solutions for some quadratic equation and very possible representations of date and time. I haven't checked Ito his test yet, but I hope you agree that even though some implementation might claim say that a certain month has 35 days then it is obviously a bug and not according to spec. What you seem to want is a list of bugs in certain implementations according to Mauve and an explanation why that bug is or isn't solved in that implementation. We don't provide that. Even though it might be useful for some of our users. We are not building Mauve tests in order to validate Sun's implementation. Rather, we are building it to check that other implementations (including Classpath) conform to the accepted specification for Java. The ultimate specification for Java is (according to Sun) the behaviour of Sun's reference implementations. Are you suggesting that there is a more appropriate or more definitive specification of Java? If so, what is it, and why is it more appropriate or definitive? No. Since Sun says what Java is and claims trademark on products which carry that name. It is their definitive specification: The thing that according to Sun is Java. So by definition Mauve isn't The Java Testsuite. But there are publicly published documents and books about the libraries and what Mauve can claim is that it is a testsuite that follows these publicly published specification as closely as possible without favoring any actual implementation. Mauve is a reference test suite that everybody can use and study and might even adapt (to better reflect their understanding of the spec) and publish its own version, which validates differences between core library implementations. In that sense Mauve is its own specification. And for our users it is certainly very useful to use Mauve to compare implementations against the currently dominant proprietary implementation to see if another implementation can be used to easily migrate away from the that implementation. Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi Stephen, Stephen Crawley wrote: [EMAIL PROTECTED] 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 ;) ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
On Friday 28 November 2003 15:43, Dalibor Topic wrote: 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. me2 -- Chris Gray /k/ Embedded Java Solutions Embedded Mobile Java, OSGi http://www.kiffer.be/k/ [EMAIL PROTECTED] +32 477 599 703 ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi, : == Stephen Crawley [EMAIL PROTECTED] writes: : 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! I mentioned the JDK version as Sun's java version 1.4.2_02 before showing the test results. As for the correctness of the mauve testcase I made, I am confident of it. And my opinions on the discussed issue are: 1. Should the mauve test conform to Sun's implementation even if it seems incorrect? No. 2. Should GNU Classpath (or other implementations) simulate Sun's implementation even if it seems incorrect? Yes, if it is necesary. These derives from Dalibor's saying in an article of Kaffe mailing list: Date:Tue, 01 Jul 2003 03:09:43 MST Subject: Re: [kaffe] Bug report (java.io.StreamTokenizer) Respect latest JDK API specs where you can, and do as Sun does where you must ;) And in the case of 12 AM/PM issue, I do not think we should simulate Sun's bug. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi,
: == Mark Wielaard [EMAIL PROTECTED] writes:
: Looked some more at the code and I see now that the the first change was
: inside a if (time = gregorianCutover) so it now makes more sense to me.
: And the second change seems correct given the above remark.
: I'll commit it in Classpath.
There is another difference between GNU Classpath's
java/util/GregorianCalendar.java and that of kaffe.
Kaffe's was imported from GNU Classpath and modified
in the kaffe world, as described by the following
ChangeLog entry.
2003-08-16 Guilhem Lavaux [EMAIL PROTECTED]
* java/util/GregorianCalendar.java (computeTime):
12:00 midnight is AM and 12:00 noon is PM.
Here is the patch that can be applied to Revision 1.21:
--- java/util/GregorianCalendar.java.orig Thu Nov 27 15:35:08 2003
+++ java/util/GregorianCalendar.javaThu Nov 27 15:48:25 2003
@@ -402,7 +402,11 @@
{
hour = fields[HOUR];
if (isSet[AM_PM] fields[AM_PM] == PM)
- hour += 12;
+ if (hour != 12) /* not Noon */
+hour += 12;
+ /* Fix the problem of the status of 12:00 AM (midnight). */
+ if (isSet[AM_PM] fields[AM_PM] == AM hour == 12)
+ hour = 0;
}
int minute = isSet[MINUTE] ? fields[MINUTE] : 0;
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.
Here is the output of the tests.
Kaffe + kaffe's GregorianCalendar
gnu.testlet.java.util.Calendar.ampm
PASS: gnu.testlet.java.util.Calendar.ampm (number 1)
PASS: gnu.testlet.java.util.Calendar.ampm (number 2)
PASS: gnu.testlet.java.util.Calendar.ampm (number 3)
PASS: gnu.testlet.java.util.Calendar.ampm (number 4)
PASS: gnu.testlet.java.util.Calendar.ampm (number 5)
PASS: gnu.testlet.java.util.Calendar.ampm (number 6)
PASS: gnu.testlet.java.util.Calendar.ampm (number 7)
PASS: gnu.testlet.java.util.Calendar.ampm (number 8)
PASS: gnu.testlet.java.util.Calendar.ampm (number 9)
PASS: gnu.testlet.java.util.Calendar.ampm (number 10)
PASS: gnu.testlet.java.util.Calendar.ampm (number 11)
PASS: gnu.testlet.java.util.Calendar.ampm (number 12)
PASS: gnu.testlet.java.util.Calendar.ampm (number 13)
PASS: gnu.testlet.java.util.Calendar.ampm (number 14)
PASS: gnu.testlet.java.util.Calendar.ampm (number 15)
PASS: gnu.testlet.java.util.Calendar.ampm (number 16)
0 of 16 tests failed
Kaffe + GNU Classpath's GregorianCalendar
gnu.testlet.java.util.Calendar.ampm
FAIL: gnu.testlet.java.util.Calendar.ampm (number 1)
got 12:00 PM but expected 12:00 AM
FAIL: gnu.testlet.java.util.Calendar.ampm (number 2)
got 12:00 PM but expected 12:00 AM
FAIL: gnu.testlet.java.util.Calendar.ampm (number 3)
got 12:10 PM but expected 12:10 AM
FAIL: gnu.testlet.java.util.Calendar.ampm (number 4)
got 12:10 PM but expected 12:10 AM
PASS: gnu.testlet.java.util.Calendar.ampm (number 5)
PASS: gnu.testlet.java.util.Calendar.ampm (number 6)
PASS: gnu.testlet.java.util.Calendar.ampm (number 7)
PASS: gnu.testlet.java.util.Calendar.ampm (number 8)
FAIL: gnu.testlet.java.util.Calendar.ampm (number 9)
got 12:00 AM but expected 12:00 PM
FAIL: gnu.testlet.java.util.Calendar.ampm (number 10)
got 12:00 AM but expected 12:00 PM
FAIL: gnu.testlet.java.util.Calendar.ampm (number 11)
got 12:10 AM but expected 12:10 PM
FAIL: gnu.testlet.java.util.Calendar.ampm (number 12)
got 12:10 AM but expected 12:10 PM
PASS: gnu.testlet.java.util.Calendar.ampm (number 13)
PASS: gnu.testlet.java.util.Calendar.ampm (number 14)
PASS: gnu.testlet.java.util.Calendar.ampm (number 15)
PASS: gnu.testlet.java.util.Calendar.ampm (number 16)
8 of 16 tests failed
Sun's java version 1.4.2_02
gnu.testlet.java.util.Calendar.ampm
FAIL: gnu.testlet.java.util.Calendar.ampm (number 1)
got 12:00 PM but expected 12:00 AM
PASS: gnu.testlet.java.util.Calendar.ampm (number 2)
FAIL: gnu.testlet.java.util.Calendar.ampm (number 3)
got 12:10 PM but expected 12:10 AM
PASS: gnu.testlet.java.util.Calendar.ampm (number 4)
PASS: gnu.testlet.java.util.Calendar.ampm (number 5)
PASS: gnu.testlet.java.util.Calendar.ampm (number 6)
PASS: gnu.testlet.java.util.Calendar.ampm (number 7)
PASS: gnu.testlet.java.util.Calendar.ampm (number 8)
FAIL: gnu.testlet.java.util.Calendar.ampm (number 9)
got 12:00 AM but expected 12:00 PM
PASS: gnu.testlet.java.util.Calendar.ampm (number 10)
FAIL: gnu.testlet.java.util.Calendar.ampm (number 11)
got 12:10 AM but expected 12:10 PM
PASS: gnu.testlet.java.util.Calendar.ampm (number 12)
PASS: gnu.testlet.java.util.Calendar.ampm (number 13)
PASS: gnu.testlet.java.util.Calendar.ampm (number 14)
PASS: gnu.testlet.java.util.Calendar.ampm (number 15)
PASS: gnu.testlet.java.util.Calendar.ampm (number 16)
4 of 16 tests failed
The Mauve test program:
// Tags: JDK1.1
// Copyright (c) 2003 Ito Kazumitsu
// This file is part of Mauve.
package gnu.testlet.java.util.Calendar;
import gnu.testlet.Testlet;
import
Re: GregorianCalendar fixes
[EMAIL PROTECTED] 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! 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. [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.] -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi, On Fri, 2003-11-28 at 02:03, Stephen Crawley wrote: The over-arching principle for Mauve testcases is that the behavior of Sun's Java implementations is the gold standard for conformance testing. I don't agree. We should not create Mauve tests to validate some proprietary library implementation. Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Mark Wielaard [EMAIL PROTECTED] wrote: On Fri, 2003-11-28 at 02:03, Stephen Crawley wrote: The over-arching principle for Mauve testcases is that the behavior of Sun's Java implementations is the gold standard for conformance testing. I don't agree. We should not create Mauve tests to validate some proprietary library implementation. Mark I don't understand what you are saying here. We are not building Mauve tests in order to validate Sun's implementation. Rather, we are building it to check that other implementations (including Classpath) conform to the accepted specification for Java. The ultimate specification for Java is (according to Sun) the behaviour of Sun's reference implementations. Are you suggesting that there is a more appropriate or more definitive specification of Java? If so, what is it, and why is it more appropriate or definitive? -- Steve ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Hi, On Mon, 2003-11-24 at 23:57, Ito Kazumitsu wrote: 2003-11-25 Ito Kazumitsu [EMAIL PROTECTED] * java/util/GregorianCalendar.java (getLinearTime): Avoid counting the leap day of the leap year twice. (computeFields): First week of month is 1 not 0. Thanks (I made it real sentences - starting with a capital). Looked some more at the code and I see now that the the first change was inside a if (time = gregorianCutover) so it now makes more sense to me. And the second change seems correct given the above remark. I'll commit it in Classpath. Thanks for your work (and patience before it was accepted), Mark ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
: == Mark Wielaard [EMAIL PROTECTED] writes: : and to have a ChangeLog entry for this patch (Ito?). How about this? 2003-11-25 Ito Kazumitsu [EMAIL PROTECTED] * java/util/GregorianCalendar.java (getLinearTime): avoid counting the leap day of the leap year twice. (computeFields): corrected so that the first week of month is not 0 but 1. ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
Re: GregorianCalendar fixes
Mark Wielaard wrote: Hi, Since I am not a GregorianCalendar expert I was hoping that someone could review the following patch which I have in my tree from Ito Kazumitsu. He and I wrote a couple of mauve test cases which are fixed by this and I see no new failures. But people didn't seem to be completely comfortable with it back in Augustus/September. It would be nice if we could create even more test cases to make sure that nothing else breaks and to have a ChangeLog entry for this patch (Ito?). Don't really have have time to learn about Calendars so I am just re-posting this patch in the hope that someone can review it. I am not expert enough for a review ;) But here the results: http://gcc.gnu.org/ml/gcc-testresults/2003-11/msg00990.html CHeers, Andreas ___ Classpath mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/classpath
