RandomAccess Interface and List Heirarchy

[Peter Levart]

On 9/25/19 12:15 PM, Remi Forax wrote:
> that said, i believe we should deprecate LinkedList (and any other List implementation that doesn't implement RandomAccess) because there are too much code out there that suppose that list.get() is O(1).

Hi Remi,

Deprecating LinkedList as a whole is maybe to harsh. LinkedList is a 
List, but it is also the only JDK implementation of single-threaded 
linked Deque, which, although a retrofitted feature, is a perfectly 
fitted feature of LinkedList. That brings me to the question: Is it 
possible and how to deprecate only one aspect of a particular 
implementation - in this case the List interface of the LinkedList? In 
this concrete case, and also because it would be strange to have a class 
called LinkedList implementing only Deque interface, it may be an 
alternative to 1st create a replacement in the form of LinkedDeque 
implements Deque, and then deprecating the whole LinkedList.

As always there are pros and cons to a particular "solution":

1. Do nothing
pros:
- no refactoring of old code needed
cons:
- performance problems continue as inexperienced programmers couple 
LinkedList with typical indexed accesses of List interface
- hard discoverability of single-threaded "linked" Deque implementation 
continues - LinkedList is not a name that comes to mind when searching 
for Deque implementation - this is less of a problem nowadays as we have 
tools like Ctrl-H in IDEA, ...

2a. Deprecate the List aspect of LinkedList and eventually remove the 
List interface from the LinkedList
pros:
- performance problems eventually solved
- at least some of the usages of LinkedList would remain valid: Deque<T> 
d = new LinkedList<>();
cons:
- compatibility risk - all uses of LinkedList that assume it implements 
List interface will have to be refactored
- hard discoverability of single-threaded "linked" Deque implementation 
continues - LinkedList is not a name that comes to mind

2b. Deprecate the List aspect of LinkedList with not planned removal of 
the List interface from the LinkedList
pros:
- performance problems eventually solved
- at least some of the usages of LinkedList would remain valid: Deque<T> 
d = new LinkedList<>(); not even warnings suppression would be needed
- no immediate compatibility risk - only suppressing warnings may be 
needed in short term
cons:
- hard discoverability of single-threaded "linked" Deque implementation 
continues - LinkedList is not a name that comes to mind

3. Create a replacement LinkedDeque implementation of Deque and 
deprecate LinkedList (with no planned removal)
pros:
- performance problems eventually solved as new code typically would 
refrain from using LinkedList for the List purpose and would start using 
LinkedDeque for the Deque purpose
- no refactoring of old code needed (at least not in the near future)
- better discoverability of single-threaded "linked" Deque implementation
cons:
- new type to learn
- code using new type would not compile/run on old JDKs - adoption rate 
of new type would be slow


2b is most promising IMO. But is there an effective way to deprecate the 
List aspect of the LinkedList? What would be needed is a particular use 
of @Deprecated annotation that would cause usages like this:

     List<T> l = new LinkedList<>();

produce compile-time deprecation warnings, but usages like this:

    Deque<T> d = new LinkedList<>();

not produce warnings.

The 1st thing that comes to mind is adding a TYPE_USE to the list of 
@Target(s) of the @Deprecated annotation and then using it like this:

public class LinkedList<E>
     extends AbstractSequentialList<E>
     implements @Deprecated List<E>, Deque<E>, Cloneable, 
java.io.Serializable


Would this make sense?


Regards, Peter