ArrayList Methods

The import statement has to name the package the class actually belongs to. The section states plainly that ArrayList is in java.util and must be imported, and every code example in the topic opens with that import before the constructor call that creates an empty list.

• A is not correct: The section places ArrayList in java.util, so naming a different package in the import does not reach the class.
• B is not correct: This names a package the section never associates with ArrayList, so the import would not make the list class available.
• D is not correct: The section says directly that ArrayList must be imported, so leaving the import out is not an option.

These two properties are what separate an ArrayList from the arrays of Topic 4.3. Because the collection can grow and shrink while a program runs, methods such as add and remove change its size. Because it holds references to objects rather than primitive values, a primitive element type has to be written as its wrapper class.

• A is not correct: A fixed length is the array property; the constructor here makes an empty list of size 0 that later calls can grow.
• C is not correct: Since the list stores references to objects, a primitive element type must be written with its wrapper class, such as Integer for int.
• D is not correct: The current element indexes run from 0 through size() - 1, so the first element sits at index 0.

The type inside the angle brackets states what kind of object the list may store, and it also fixes the parameter and return types of the list's methods. Reading a signature means replacing every E with that element type, the same way the section replaces E with String for an ArrayList<String>.

• A is not correct: get(index) returns the single element selected by that index, not an array holding the collection.
• B is not correct: An ArrayList stores object references, and the element type named in the angle brackets here is Badge, not a primitive.
• C is not correct: That is the type of the whole list; get reaches inside the list and hands back one element from it.

The type written inside the angle brackets states what kind of object the list may store. Because a primitive is not an object reference, a primitive element type is written as its wrapper class, and the section's own example of removing by index uses ArrayList<Integer> to hold whole numbers.

• B is not correct: The element type has to name an object type, and the section says a primitive element type uses its wrapper class instead.
• C is not correct: This is an array, so its length is fixed; the question asks for the type that stores the values in an ArrayList.
• D is not correct: This is also an array rather than an ArrayList, so it cannot grow and shrink as elements are added or removed.

An array reports its length with the field length, but an ArrayList reports its element count with the method size(). Each one-argument add appends an element, so tracing the size means counting the calls that changed the list.

• A is not correct: 0 is the size the constructor produces, before either add call has appended anything.
• B is not correct: This counts only one of the two appends; both add calls run, and each one adds an element.
• D is not correct: The elements are String values going into an ArrayList<String>, so the element type matches and the code compiles.

set(index, obj) does two things at once: it puts the new object at that index and it hands back the element that used to be there. Reading the printed line means keeping those two values apart, since the returned value is the old one and the list now holds the new one.

• A is not correct: This treats the list as unchanged, but set replaces the element at that index, so get(0) no longer reads the original value.
• C is not correct: This reverses the two roles; the value handed back by set is the element formerly at that index, not the replacement.
• D is not correct: This assumes set returns its new argument, but the section says it returns the old element.

The return value of boolean add(E obj) is not a report on whether anything unusual happened; the section says it appends and returns true. The size then follows from counting appends, starting from the 0 that the constructor produced.

• B is not correct: 0 is the size of the newly constructed list; the append has already run before size() is called.
• C is not correct: The one-argument add returns true, so the boolean variable cannot hold the opposite value.
• D is not correct: The element type is the wrapper Double and the value added is a decimal number, so nothing conflicts and the code runs.

For indexed add, the valid insertion positions before the call are 0 through size(), inclusive, and position size() means the end of the list. Because the value is appended rather than inserted ahead of anything, no earlier element shifts, and get returns the element itself.

• A is not correct: The first element keeps index 0 here, since inserting at position size() adds after it and shifts nothing.
• B is not correct: get(index) returns the element stored at that index, not a number describing the position.
• C is not correct: This is the index passed to get, but the method hands back the element found there instead of the index.

Replacement changes one position and leaves the rest of the list alone. Unlike indexed add and remove, set does not shift any element and does not change the size, so only the value at that one index differs afterward.

• A is not correct: The element at index 0 is never touched by a call that names index 1, so it is not what set returns.
• B is not correct: This reverses the order; the returned value is the old element and the list afterward holds the new one, not the other way round.
• D is not correct: The element at index 2 stays where it is, because set replaces in place rather than shifting later elements.

Writing the element type inside the angle brackets is what makes this check possible, which is why the section prefers ArrayList<E> over a raw ArrayList. The section shows the same failure with names.add(7) on an ArrayList<String>, where the mismatch is caught as a compile-time error.

• A is not correct: Text cannot be stored as a value of the declared wrapper element type, which is exactly the mismatch the compiler refuses.
• C is not correct: The compiler rejects the mismatched call rather than letting the program run and quietly skip that line.
• D is not correct: The element type is checked when the code is compiled, so the problem appears before any element is ever read back.

Indexed removal changes three things at once: it hands back the removed element, it moves every later element down one index, and it shrinks the list. That is why the section says to rewrite the list after every add, set, or remove before reading any further index.

• B is not correct: This leaves the list untouched, but removal both shifts the later elements left and decreases the size by 1.
• C is not correct: remove(index) returns the element it took out at that index, which here is the first element, not the one that moves into its place.
• D is not correct: This both misreports what remove returns and keeps the original count, ignoring the decrease in size.

After a removal the indexes of every later element change, so any get that follows has to be read against the rewritten list rather than the original one. The size decreases by 1 at the same time, which is why both printed values differ from what the list held before the call.

• A is not correct: This value is the element that was removed, so it is no longer in the list to be found at any index.
• B is not correct: This is the element at index 0; the shift moves later elements down, but it does not move the first element.
• C is not correct: The size decreases by 1 when an element is removed, so the count cannot stay at its earlier value.