0

I have an abstract class A such that it contains a method sort which clashes with the sort method in java.util.List

 public abstract class A<T> extends AbstractList<T> implements
   RandomAccess {
       //bunch of stuff 
        public void sort(final Comparator<T> comparator) {
        java.util.Collections.sort(this, comparator);
    }
  }

I read all the linked answers on generics type erasure and I do know that why they have the same name clash. However, I don't want to just change the name of my method to get rid of this error. Since class A extends AbstractList which in turn implements List, somehow the solution given in the linked questions are unable to help me to get through this situation.

P.S. I am well aware that this is a redundant/duplicate question, however, it may address a situation which may or may not exist and is no doubt dependent on my novelty of the concept. I was unable to find a SO question which deals with such a situation.

List of questions:

  1. interface and a class. name clash: same erasure, yet neither overrides other

  2. Implementing Comparable, compareTo name clash: "have the same erasure, yet neither overrides the other"

  3. JAVA GENERICS ERROR: have the same erasure, yet neither overrides the other

learn_java
  • 31
  • 4
  • 5
    You can fix the method signature to accept `Comparator super T>`, but your implementation will cause a stack overflow, because `Collections.sort()` calls `List.sort()`. So the real question is, why not simply delete your method and use the default implementation? Btw, you haven't linked any questions. – shmosel Feb 28 '17 at 03:39
  • @shmosel The method is necessary since it is overridden by other classes which extend this class A and perform sorting on Immutable or Synchronised versions of lists. Also, can you please elaborate or point to a resource which elaborates on this new ironic situation of stack overflow caused by **Collections.sort()** calling **List.sort()** – learn_java Feb 28 '17 at 03:48
  • For synchronization, you'll want to override it in the subclass and call `super.sort(comparator)`. For immutability, you *may* want to override it to deprecate it and/or throw an exception (you'll probably get an exception either way). Neither should affect your abstract class, though. – shmosel Feb 28 '17 at 03:53
  • @shmosel So, what do you suggest? Should I risk stack overflow via your solution or simply refactor the method? – learn_java Feb 28 '17 at 03:58
  • Re: the stack overflow, there's not much to elaborate. If you look at the source code, you'll see that [`Collections.sort()`](http://grepcode.com/file/repository.grepcode.com/java/root/jdk/openjdk/8u40-b25/java/util/Collections.java#Collections.sort%28java.util.List%2Cjava.util.Comparator%29) calls `list.sort()`, where the actual sort is delegated to `Arrays.sort()`. (This change happened in Java 8.) If you're going to override `sort()`, you would have to implement it yourself. Note that you would be required to follow the contract of `sort(null)` using natural ordering where applicable. – shmosel Feb 28 '17 at 03:58
  • My suggestion would be to delete the method, as I said initially. – shmosel Feb 28 '17 at 03:59

0 Answers0