This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
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.
i have a suspicion, which may be ill-founded, that the un-resizability of arrays goes back to the history of programming languages.
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 ]
Joined: Jan 29, 2005
It's the no free lunch theorem
Joined: Jan 29, 2003
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.