ArrayList is like Vector without the synchronisation overhead. In Java version 1.1 ArrayList is about 3-4 times faster than Vector, though with JDK (Java Development Kit) 1.1.4+ the difference is not so pronounced. (Rolling your own array is about 40 times faster than Vector.) For compatibility with versions of Java prior to Java version 1.1, you need to use Vector instead. Don’t use Vector in new code. It has confusing redundant methods and the synchronisation is excessive and implicit.
You can check if a List is in order with com.mindprod.common18.InOrder.
|Adding Elements||ArrayList ⇔ array|
// adding an element to the middle of a list arrayList.add( i, object ); // adding an element to the end of a list arrayList.add( object );
actually inserts, sliding existing elements up to make room. As you might guess, this is an expensive operation when there are many elements.
With an ordinary ArrayList you can’t set elements until you have grown the ArrayList sufficiently first with add. If you try it, you will get an ArrayIndexOutOfBoundsException or IndexOutOfBoundsException.
If you want an ArrayList that grows automatically when you use a set index too big, here is the complete source code for it.
Ordinary ArrayList has no setSize or setLength method. You cannot grow the list by more than one element at a time.
If you have an Iterator running, you must use Iterator.remove, not ArrayList.remove.
ArrayList.clear sets each of the elements to null, then sets the size to 0 However, it does not reallocate the array.
When you are done removing elements, you have logically removed them, but the RAM (Random Access Memory) they had allocated is still nailed down, ready to use for future growth. If you want to reclaim it, you must use ArrayList. trimToSize(), which allocates a new internal array just the right size and copies everything over from the new one, and discards the old one to be later garbage collected. You don’t normally want to use trimToSize unless you know the ArrayList is not going to grow again, any time soon. It is a relatively costly operation, so you don’t want to do it just to reclaim a handful of bytes. You might use it after a massive pruning, or after you were sure nothing new was coming.
When I am absolutely sure there are no new elements coming for the ArrayList, I typically use toArray and use the much faster raw array from then on. I think of ArrayLists mainly as tools to build a Collections and I think of arrays as tools to process them. However, most other programmers are not nearly so keen as I am on naked arrays. They prefer to do everything with ArrayLists. when you use generics and for:each it is relatively easy to flip back and forth between each style.
ArrayList.add or ArrayList. addAll will not discard duplicates. To do that you would need to check with ArrayList.contains before adding, or create a HashSet which naturally dedups, then use ArrayList. addAll to effectively convert it to an ArrayList.
More complex conversions can be handled by combining ArrayList. toArray, List.subList, Arrays.copyOf, Arrays. copyOfRange and System. arraycopy. subList does not make a copy. Any changes to the sublist are reflected in the original. System.arraycopy is quite general letting you pick the offset in both the source and destination. Arrays. copyOf creates a new array, grown or shrunk. Arrays. copyOfRange creates a new array, allowing you to specify the offset in the source.
I wrote a method of the form:
IntelliJ complained this was a wicked thing to do. Why? Because the caller could modify the String array and it would wreck my copy inside someMethod. So what do people do? They use Arrays.asList to convert to a List, (it turns out a java.util.Arrays.ArrayList). But the List still lets the user modify the fields which in turn modify the underlying array. We have gained nothing.
We also have to use Collections.unmodifiableList which gives us a java.util.Collections.UnmodifiableRandomAccessList wrapper around our List that throws a UnsupportedOperationException when we attempt to write.
The catch is the set methods are still there. We don’t find out about the problem of their use modifying this List until run time.
I hope it is obvious, but as Leif Roar Moldskred pointed out the problem isn’t that you’re returning something the client can modify. The problem is that you’re giving the client backdoor access into this object’s private state: if you just return your internal array any changes the client does to that array are a change in the state of this. If you return a copy of the internal array, or a list created from the internal array, any changes made to the return value by the client only affects the client’s state, not thiss. So an alternative way to handle this is to return a clone of the array.
To get the thread safety of Vector in ArrayList wrap it like this:
// making an ArrayList threadsafe ArrayList a = new ArrayList( 100 ); Collection threadSafeList = Collections.synchronizedCollection( a );
Using an ArrayList with generics:
This page is posted
Optional Replicator mirror
Your face IP:[188.8.131.52]
You are visitor number|