-
Enhancement
-
Resolution: Won't Fix
-
P4
-
None
-
8u25
-
generic
-
generic
FULL PRODUCT VERSION :
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
timsort, now used for Collections.sort() and Arrays.sort() throws NPE if there are any nulls. This was there in jdk7 as well. It's occuring to me that it would be impossible for anyone not to have noticed this by now, right? Is this functionality by design? Wait til it's half way through sorting and gag? Seems wrong... morally. You could at least throw a nice TimCantHandleNullsException ;o) Seems more useful to add a null check. ComparableComparator can't handle nulls either so maybe Oracle's vision of java is to be null intolerant. I guess that's why the world needs apache commons, for null checks ;o)
java.util.ComparableTimSort.countRunAndMakeAscending(Object[] a, int lo, int hi)
if (((Comparable) a[runHi++]).compareTo(a[lo]) < 0) { // Descending
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Integer[] array = new Integer[3];
array[0] = 0;
array[2] = 2;
Arrays.sort(array);
List<String> list = new ArrayList<String>();
list.add("foo");
list.add("bar");
list.add("baz");
list.set(1, null);
Collections.sort(list);
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
order is restored
ACTUAL -
NPE, stacktrace, chaos...
ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.NullPointerException
at java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:316)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:184)
at java.util.Arrays.sort(Arrays.java:1246)
at TimSortTest.testMe(TimSortTest.java:18)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;
import org.junit.Test;
public class TimSortTest
{
@Test
public void testMe() {
Integer[] array = new Integer[3];
array[0] = 0;
array[2] = 2;
Arrays.sort(array);
}
@Test
public void testMeToo() {
List<String> list = new ArrayList<String>();
list.add("foo");
list.add("bar");
list.add("baz");
list.set(1, null);
Collections.sort(list);
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Provide a comparator that can handle the null -- this is why I haven't run across it in the past, I have always provided a comparator and my code can handle nulls.
java version "1.8.0_25"
Java(TM) SE Runtime Environment (build 1.8.0_25-b18)
Java HotSpot(TM) 64-Bit Server VM (build 25.25-b02, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
timsort, now used for Collections.sort() and Arrays.sort() throws NPE if there are any nulls. This was there in jdk7 as well. It's occuring to me that it would be impossible for anyone not to have noticed this by now, right? Is this functionality by design? Wait til it's half way through sorting and gag? Seems wrong... morally. You could at least throw a nice TimCantHandleNullsException ;o) Seems more useful to add a null check. ComparableComparator can't handle nulls either so maybe Oracle's vision of java is to be null intolerant. I guess that's why the world needs apache commons, for null checks ;o)
java.util.ComparableTimSort.countRunAndMakeAscending(Object[] a, int lo, int hi)
if (((Comparable) a[runHi++]).compareTo(a[lo]) < 0) { // Descending
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Integer[] array = new Integer[3];
array[0] = 0;
array[2] = 2;
Arrays.sort(array);
List<String> list = new ArrayList<String>();
list.add("foo");
list.add("bar");
list.add("baz");
list.set(1, null);
Collections.sort(list);
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
order is restored
ACTUAL -
NPE, stacktrace, chaos...
ERROR MESSAGES/STACK TRACES THAT OCCUR :
java.lang.NullPointerException
at java.util.ComparableTimSort.countRunAndMakeAscending(ComparableTimSort.java:316)
at java.util.ComparableTimSort.sort(ComparableTimSort.java:184)
at java.util.Arrays.sort(Arrays.java:1246)
at TimSortTest.testMe(TimSortTest.java:18)
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
import java.util.ArrayList;
import java.util.Arrays;
import java.util.Collections;
import java.util.List;
import org.junit.Test;
public class TimSortTest
{
@Test
public void testMe() {
Integer[] array = new Integer[3];
array[0] = 0;
array[2] = 2;
Arrays.sort(array);
}
@Test
public void testMeToo() {
List<String> list = new ArrayList<String>();
list.add("foo");
list.add("bar");
list.add("baz");
list.set(1, null);
Collections.sort(list);
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Provide a comparator that can handle the null -- this is why I haven't run across it in the past, I have always provided a comparator and my code can handle nulls.