RandomAccess Interface and List Heirarchy

Remi Forax forax at univ-mlv.fr
Wed Sep 25 10:15:40 UTC 2019

Hi Cyrus,
as the javadoc says RandomAccess is a marker interface,
an interface used at runtime to indicate if the implementation provides a fast random access operation or not.

"marker interface" is the precursor of a runtime visible annotation.
RandomAccess was introduce in 1.4 while annotations were introduced later in 1.5.

implementing RandomAccess is equivalent of adding a bit on all implementations of List,
so casting an instance to RandomAccess is not how you should using it.

More generally, the idea of the collection API is that instead of having a RandomAccessList, a MutableList, an ImmutableList, a RandomImmutableList, etc you have only one type java.util.List and if you want to know more either you do a instanceof check, or call a method that throws UnsuportedOperationException or use a method of the API that does the runtime checks for you, like by example List.copyOf().

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).


----- Mail original -----
> De: "Cyrus Vafadari" <cvafadari at gmail.com>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Envoyé: Mercredi 25 Septembre 2019 05:19:49
> Objet: RandomAccess Interface and List Heirarchy

> Hello all,
> *TLDR: Why doesn't RandomAccess interface extend List?*
> I'm maintaining a framework that lets developers build plugins, and
> developers implement a `put(List<Thing> thingList)` in their plugins.
> However, I want to guarantee to the implementer that their List will
> support RandomAccess. I see Java does support a syntax for declaring that
> the argument should implement both List and RandomAccess using the "&"
> operator, and I could declare my own interface that extends both, but I am
> surprised that RandomAccess itself does not extend List and appear in the
> List hierarchy. According to the docs, it only applies to List
> implementations anyway, and we use `instanceof` extensively in the code to
> bifurcate how we handle both cases. It seems more natural to me for
> RandomAccess to extend List, so that I can let my implementer know
> explicitly they can rely on RandomAccess.
> I am happy to give more details on my scenario, and very excited to learn
> more why this decision was made, and if there is an aspect I am missing or
> if improvements could be made!
> Best wishes,
> Cyrus

More information about the core-libs-dev mailing list