mono-thread concurrent modification

[Thomas Hawtin]

Based on what?

Implementation of java.util.RandomAccess and size.

Tom Hawtin

 

[Chris Uppal]

That's not "wrong". It might give you poor performance in unusual cases,
but so might many things.

What is /wrong/ IMO is not calling get(int) on a LinkedList, but that
LinkedList advertises itself as /suitable/ for (routinely) calling get(int). I
see no reason why LinkedList shouldn't have a get(int) method -- although a
better name might be searchForItemAtIndex(int) -- but that doesn't mean that it
should present itself as interchangable (in this respect) with an ArrayList.

Put it this way, are there any circumstances where it is appropriate to use
get(int) on a LinkedList without knowing that it /is/ a LinkedList ?

The contract implied by an interface doesn't stop at the subtype
relationship -- it is not enough simply to provide methods with the expected
signatures, they should also behave as expected.

public class XList<E>
implements List<E>
{
//... routine stuff

E get(int i)
{
System.exit(i);
}

//... more routine stuff
}

In what useful sense is that a List over and above being a Collection ?

-- chris

 

[Chris Uppal]

There is no must about it. Indeed java.util.Collections takes a smarter,
adaptive approach.

To my mind, the use of the RandomAccess marker in Collections is better
characterised as indefensible switch-on-type than good programming. Same goes
for java.util.AbstractList.subList(int, int) -- which is the /only/ other place
where that marker interface is used[*] in the entire 1.5 JRE.

-- chris

([*] as the target of an instanceof or checkcast bytecode)

 

[Mike Schilling]

There is no must about it. Indeed java.util.Collections takes a smarter,
adaptive approach.

To my mind, the use of the RandomAccess marker in Collections is better
characterised as indefensible switch-on-type than good programming. Same
goes
for java.util.AbstractList.subList(int, int) -- which is the /only/ other
place
where that marker interface is used[*] in the entire 1.5 JRE.

I presume that RandomAccess is new for 1.5; I was unaware of it. It makes
much less sense as a marker interface than as the place where get() etc. are
defined.

 

[Mike Schilling]

It should be. Else you've done it wrong.


I'd be much more happy going into production with something that wasn't
heavily optimised than something that stopped working.

Normal unit testing will find the exception, but not the performance
problem.

 

[Thomas Hawtin]

I presume that RandomAccess is new for 1.5; I was unaware of it. It makes
much less sense as a marker interface than as the place where get() etc. are
defined.

No, it was in 1.4.

http://java.sun.com/j2se/1.4.2/docs/guide/collections/changes4.html

Tom Hawtin

 

[John C. Bollinger]

Most uses of Lists are random access,

The vast majority of *my* uses of Lists are serial access. It is quite
rare that I both want some element in the middle of a List and also know
its index. The most common exception is sorting, but I don't do that
often. On the other hand, ArrayList is the List implementation I
usually use, whether I anticipate random access or not.