Most of the generics changes that your average Java programmer will see are in the collections API and in extending those collections. The collections become easier to use and the compiler supports typing, as we saw above. Gone are the days when you created your own collection type to hold only one type of object; generics makes that code unnecessary.
The way generics change collections is not the end of the story. Code designers will be using generics to make code more flexible in more than just collections. If the generics change had only changed collections, Java would have been better off adding a dynamic array type.
What the author probably meant to say was: If the only reason why generics were added to Java is because Sun wanted to add type safe collections to the language, then we wouldn't have needed such a completely new and powerful concept as generics. Type safe collections could have been implemented in a much more simple way, by providing a dynamic array type (i.e. an array that can dynamically resize).
What it basically comes down to is that there are more reasons than just type safe collections to add generics to the Java language.
Type safe collections could have been implemented in a much more simple way, by providing a dynamic array type (i.e. an array that can dynamically resize).
The thing I don't understand is the reason behind this assertion. First we already have dynamic arrays in Java (anyone said Vector, List?).
Second, I don't see how dynamic arrays can help you with turning all collections into type safe? Some collections are not linear, but trees, dynamic lists etc.
The collections offer rough equivalents of dynamically sized arrays, not real dynamic arrays. If arrays could really resize themselves, making up some non-existant syntax, this one:
String myStrings = new String[?];
would be simpler (the original quote suggests) than
Vector<String> myStrings = new Vector<String>();
as long as coders don't want more from generics than typesafe bags - either arrays or collections.
[ April 17, 2007: Message edited by: Stan James ]
An array was originally set up using "indexed addressing," where the processor is given the memory address of the first element, and all the other elements occupy the subsequent memory addresses. Passing an array name and an index allows the processor to add the index to the original address and find the required element very quickly [beware: oversimplification!]. So an array uses what is incorrectly called random access to find its elements, and also has a structure which matches the repeating structure of the hardware (memory). Some languages (eg C) will allow the programmer to find the actual memory location (from a pointer), and add 1 to it to get the next element.
But the memory location one beyond the end of the address will contain something different . . .
This means that increasing the size of an array either means using indirect addressing (the last element contains the memory location for the continuation, but it is awkward for the computer to distinguish the different type of addressing), or moving the whole thing to a new memory location. I presume this latter is what the collections framework does; Vector and ArrayList actually call (directly or indirectly) the System.arraycopy method.
Which means it is awkward to design the concept of a resizable array.
[ April 17, 2007: Message edited by: Campbell Ritchie ]
So to make those non linear collections type safe you would have to implement generics.
Gotcha. I'm trying to think if I've ever had to rely on the non-linear properties of any collection ... blank so far. Or am I missing something really obvious?
VB has resizable arrays with redim. It's manual and probably pretty expensive. Unless they simulate an array with a linked list (!) I guess they copy the old array to a new one.