JDK-8030848 : Collections.sort(List l, Comparator) should defer to List.sort(Comparator )
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.util:collections
  • Affected Version: 8,9
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2013-12-20
  • Updated: 2015-05-15
  • Resolved: 2014-01-16
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
8u20Fixed 9 b02Fixed
The implementation of the method Collections.sort(List l, Comparator)  should be implemented as follows:

    @SuppressWarnings({"unchecked", "rawtypes"})
    public static <T> void sort(List<T> list, Comparator<? super T> c) {

and the default implementation in List.sort should be the previous implementation of Collectors.sort:

    default void sort(Comparator<? super E> c) {
        Object[] a = toArray();
        Arrays.sort(a, (Comparator)c);
        ListIterator<E> i = listIterator();
        for (Object e : a) {
            i.set((E) e);

Thus ensuring that Collection.sort will use the most optimal sort implementation provided by the list implementation.
At least one third party library (JDiagram) does have an ExtendedArrayList subclass that overrides sort() and defers to Collections.sort(). This causes a StackOverflowError: http://stackoverflow.com/questions/29069363/jdiagram-older-version-throwing-stackoverflowerror-with-jre-8-at-extendedarrayli That was with an old version though. They have apparently released a newer version for Java 8 that doesn't have this problem.

Release team: Approved for deferral to 8u20. You'll have to create a backport and target it to 8u20 to get it in.

@Mark, there is no such subclasses in the JDK itself that behave this way (otherwise the changeset to 9 would have updated such code). The concern is a third party subclass of List written and tested against Java 8 and then run against Java 9. That subclass could override List.sort with an implementation that defers to Collection.sort (why? i dunno, it would be silly to do so but...). I think it is an edge case rather than something theoretical. If we don't backport to 8 i think we should in the 8u that follows to reduce the gap.

Are there any such subclasses of List in the JDK itself? Or is this more a theoretical concern?

Requesting a backport to 8. Patch approved and pushed to 9. Patch to 8 is identical. Note that this change does not affect the specification even though it may appear to do so, the document changes are just refactorings preserving the normative behaviour. Risk is low. Testing in 8 has not resulted in any regressions. If this fix is not backported to an 8 release we risk the possibility of stack overflows for sub-classes of List that override the List.sort method and defer to Collections.sort, which is an edge case but still might occur. In that respect it is better to fix in 8 rather than an 8u to avoid any such possibility.