Analysis of Mauve failures - Part 2

Thu Apr 4 05:32:00 GMT 2002

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.
