Re: Analysis of Mauve failures - Part 2

[Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>]

Mark Wielaard wrote:

>got 'Fri, 18 May 2001 10:18:06 PDT' but expected
>    'Fri, 18 May 2001 17:18:06 GMT'
>Are we missing a Calendar.setTimeZone() somewere?
>

TimeZone and Calendar stuff is known to be somewhat buggy in libgcj so 
it wouldn't surprise me if something really is wrong here.

>>FAIL: gnu.testlet.java.util.ArrayList.AcuniaArrayListTest: should throw an IndexOutOfBoundsException -- 3 (number 1)
>>
>removeRange(3,2) called on an ArrayList of 14 elements.
>Seems reasonable but spec does not explicitly specify this behaviour.
>

Hehe, our javadoc says "You asked for it if you call this with invalid 
arguments", which isn't unreasonable given that its a protected method. 
But it doesn't seem expensive to change it to behave like the JDK 
implementation:

Index: ArrayList.java
===================================================================
RCS file: /cvs/gcc/gcc/libjava/java/util/ArrayList.java,v
retrieving revision 1.9
diff -u -r1.9 ArrayList.java
--- ArrayList.java      2002/01/22 22:40:38     1.9
+++ ArrayList.java      2002/04/04 01:37:55
@@ -444,12 +444,14 @@
    */
   protected void removeRange(int fromIndex, int toIndex)
   {
-    if (fromIndex != toIndex)
+    if (fromIndex <= toIndex)
       {
         modCount++;
         System.arraycopy(data, toIndex, data, fromIndex, size - toIndex);
         size -= toIndex - fromIndex;
       }
+    else
+      throw new ArrayIndexOutOfBoundsException();
   }
 
   /**

>>FAIL: gnu.testlet.java.util.ArrayList.AcuniaArrayListTest: should throw a ConcurrentModificationException -- 7 (number 1)
>>
>set(int, Object) does not make the Iterator throw a
>ConcurrentModificationException. Seems to not be required by the spec
>though.
>

set() should not update modCount (and thus not cause iterators to throw 
ConcurrentModificationException), because it is not a structural change 
to the list. Only operations that could result in adding or removing 
entries should update modCount. So, the test is wrong.

>>FAIL: gnu.testlet.java.util.Arrays.sort (number 1)
>>FAIL: gnu.testlet.java.util.Arrays.sort (number 2)
>>FAIL: gnu.testlet.java.util.Arrays.sort (number 3)
>>FAIL: gnu.testlet.java.util.Arrays.sort (number 4)
>>FAIL: gnu.testlet.java.util.Arrays.sort (number 5)
>>FAIL: gnu.testlet.java.util.Arrays.sort (number 6)
>>FAIL: gnu.testlet.java.util.Arrays.sort (number 7)
>>FAIL: gnu.testlet.java.util.Arrays.sort (number 8)
>>FAIL: gnu.testlet.java.util.Arrays.sort (number 9)
>>FAIL: gnu.testlet.java.util.Arrays.sort (number 10)
>>
>Ugh. Our sort does not sort...
>Some example failures:
>
>- 79,84,94,42,84,75,11,52,84,18,69,76,14,69,32,28,49,87,98,39,.
>+ 11,14,18,28,32,39,42,49,52,69,79,69,75,76,84,84,84,87,94,98
>

Oh, crap ;-(. I thought I had fixed these last year. Either I was wrong 
or someone has broken them again.

>>FAIL: gnu.testlet.java.util.Hashtable.AcuniaHashtableTest: should throw NullPointerException (number 1)
>>
>Our docs say: "This is the new API for the old contains(), except that
>it is forgiving of null."
>But the spec says "Note that this method is identical in functionality
>to contains"
>

This is a bug in Hashtable. Probibly the wrong code has been 
accidentally pasted in from HashMap. I'll check in a patch soon.

>>FAIL: gnu.testlet.java.util.Hashtable.AcuniaHashtableTest: should throw NullPointerException -- 1 (number 1)
>>
>remove(null). Our docs say "Map.remove and Dictionary.remove disagree
>whether null is a valid parameter; at the moment, this implementation
>obeys Map.remove, and silently ignores null."
>

It should throw for a null argument. Another bug.

>>FAIL: gnu.testlet.java.util.LinkedList.AcuniaLinkedListTest: should throw a ConcurrentModificationException -- 7 (number 1)
>>
>Same issue as with ArrayList.
>set(int, Object) does not make the Iterator throw a
>ConcurrentModificationException. Seems to not be required by the spec
>though. Do people depend on this behaviour?
>

Not a bug, the test is wrong.

regards

Bryce.