classpath-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[cp-patches] Re: DataFormat.equals() reimplemented


From: David Gilbert
Subject: [cp-patches] Re: DataFormat.equals() reimplemented
Date: Tue, 26 Jul 2005 15:22:13 +0000
User-agent: Mozilla Thunderbird 1.0.2 (X11/20050426)

Mark Wielaard wrote:

>Hi,
>
>This is a reimplementation of DateFormat.equals() following the JCL book
>description. While testing this I found that David already created Mauve
>tests for this which closely follow this description already.
>
>2005-07-26  Mark Wielaard  <address@hidden>
>
>        * java/text/DateFormat.java (equals): Reimplement.
>
>This makes all DateFormat tests in Mauve pass except one. The failure is
>when the mauve test sets the TimeZone of the Calendar of the DateFormat
>object to a different TimeZone, but with the same rules. As explained in
>the new documentation I believe this test is wrong. Or at least I don't
>see why it would matter or a way to test for it. But I may be wrong.
>
>David, do you have a comment/suggestion for this patch/test?
>
>Cheers,
>
>Mark
>  
>
>------------------------------------------------------------------------
>
>Index: java/text/DateFormat.java
>===================================================================
>RCS file: /cvsroot/classpath/classpath/java/text/DateFormat.java,v
>retrieving revision 1.21
>diff -u -r1.21 DateFormat.java
>--- java/text/DateFormat.java  23 Jul 2005 20:25:15 -0000      1.21
>+++ java/text/DateFormat.java  26 Jul 2005 13:20:35 -0000
>@@ -405,8 +405,18 @@
>    * <ul>
>    * <li>Is not <code>null</code>.</li>
>    * <li>Is an instance of <code>DateFormat</code>.</li>
>-   * <li>Has the same numberFormat field value as this object.</li>
>+   * <li>Has equal numberFormat field as this object.</li>
>+   * <li>Has equal (Calendar) TimeZone rules as this object.</li>
>+   * <li>Has equal (Calendar) isLenient results.</li> 
>+   * <li>Has equal Calendar first day of week and minimal days in week
>+   * values.</li>
>    * </ul>
>+   * Note that not all properties of the Calendar are relevant for a
>+   * DateFormat. For formatting only the fact whether or not the
>+   * TimeZone has the same rules and whether the calendar is lenient
>+   * and has the same week rules is compared for this implementation
>+   * of equals. Other properties of the Calendar (such as the time)
>+   * are not taken into account.
>    *
>    * @param obj The object to test for equality against.
>    * 
>@@ -419,8 +429,24 @@
>       return false;
> 
>     DateFormat d = (DateFormat) obj;
>+    TimeZone tz = getTimeZone();
>+    TimeZone tzd = d.getTimeZone();
>+    if (tz.hasSameRules(tzd))
>+      if (isLenient() == d.isLenient())
>+      {
>+        Calendar c = getCalendar();
>+        Calendar cd = d.getCalendar();
>+        if ((c == null && cd == null)
>+            ||
>+            (c.getFirstDayOfWeek() == cd.getFirstDayOfWeek()
>+             &&
>+             c.getMinimalDaysInFirstWeek()
>+             == cd.getMinimalDaysInFirstWeek()))
>+          return ((numberFormat == null && d.numberFormat == null)
>+                  || numberFormat.equals(d.numberFormat));
>+      }
> 
>-    return numberFormat.equals(d.numberFormat);
>+    return false;
>   }
> 
>   /**
>  
>
Hi Mark,

I wasn't sure from your description exactly which test fails, and I
can't run the tests against Classpath myself right now because just
today my 'jamvm' stopped working:

address@hidden ~/workspace/mauve $ jamvm -classpath .
gnu.testlet.SimpleTestHarness -file DateFormatTests.txt -debug -verbose
Cannot create system class loader
Exception occured while printing exception (java/lang/RuntimeException)...
Original exception was java/lang/NoSuchFieldError

>From memory, I used the hint in the Sun Java bug reports that
DateFormat.equals() relies on the "equivalence" of the Calendars rather
than their equality, and made the tests by guessing what "equivalence"
means.   I don't recall if the JCL book had any more details that I
relied on - I have a copy at home, so I'll take a look at that tonight.

Note that when I run the tests against the JDK, I get the following results:

address@hidden ~/workspace/mauve $ java -classpath .
gnu.testlet.SimpleTestHarness -file DateFormatTests.txt -debug -verbose
gnu.testlet.java.text.DateFormat.equals
----
PASS: gnu.testlet.java.text.DateFormat.equals (number 1)
PASS: gnu.testlet.java.text.DateFormat.equals (number 2)
PASS: gnu.testlet.java.text.DateFormat.equals (number 3)
PASS: gnu.testlet.java.text.DateFormat.equals (number 4)
PASS: gnu.testlet.java.text.DateFormat.equals (number 5)
PASS: gnu.testlet.java.text.DateFormat.equals (number 6)
PASS: gnu.testlet.java.text.DateFormat.equals (number 7)
PASS: gnu.testlet.java.text.DateFormat.equals (number 8)
PASS: gnu.testlet.java.text.DateFormat.equals (number 9)
PASS: gnu.testlet.java.text.DateFormat.equals (number 10)
PASS: gnu.testlet.java.text.DateFormat.equals (number 11)
PASS: gnu.testlet.java.text.DateFormat.equals (number 12)
PASS: gnu.testlet.java.text.DateFormat.equals (number 13)
PASS: gnu.testlet.java.text.DateFormat.equals (number 14)
PASS: gnu.testlet.java.text.DateFormat.equals (number 15)
FAIL: gnu.testlet.java.text.DateFormat.equals: uncaught exception:
java.lang.NullPointerException
java.lang.NullPointerException
        at java.text.DateFormat.equals(DateFormat.java:631)
        at java.text.SimpleDateFormat.equals(SimpleDateFormat.java:1854)
        at gnu.testlet.java.text.DateFormat.equals.test(equals.java:116)
        at gnu.testlet.SimpleTestHarness.runtest(SimpleTestHarness.java:272)
        at gnu.testlet.SimpleTestHarness.main(SimpleTestHarness.java:421)
1 of 16 tests failed

address@hidden ~/workspace/mauve $ java -version
java version "1.4.2-02"
Java(TM) 2 Runtime Environment, Standard Edition (build Blackdown-1.4.2-02)
Java HotSpot(TM) Client VM (build Blackdown-1.4.2-02, mixed mode)

Regards,

Dave




reply via email to

[Prev in Thread] Current Thread [Next in Thread]