Martin spotted a
few inconsistencies in the new Generic Collections and wonders why…
But a couple of aspects of the new generics-enabled collections framework
annoy me. For example, the Collections interface is declared as
Collection<E> and the
add method, for example, is
correctly declared as:
boolean add(E object)
So I cannot help but wonder why, then, is
remove declared as:
boolean remove(Object object)
and
Similarly, the toArray() method should be declared as follows:
E[] toArray()
Instead of:
Object[] toArray()
Rest assured, this is not an oversight, these methods were designed this way
for two very good reasons.
Can you see why?
Here are hints if you get stumped (in white):
- Existing 1.4 code would break with this definition.
- Try to implement this method for all Collections.
#1 by Reader on February 8, 2005 - 2:50 am
Cedric, URL in post has “mailto:” protocol
#2 by Valery Silaev on February 8, 2005 - 2:52 am
More on this and many other issues with generics http://www-106.ibm.com/developerworks/java/library/j-jtp01255.html
#3 by Euxx on February 8, 2005 - 10:48 pm
Bytecode tales. Erasure of Collection.toArray() method.
Cedric is objecting on Martin’s comments on generics in Collection interface. Cedric is saying that
Existing 1.4 code would break with this definition.
Try to implement this method for all Collections.
Probably ‘m missing something. L
#4 by Euxx on February 8, 2005 - 10:49 pm
A non-intrusive way to keep type information after erasure.
Major problem with erasure-based generic implementation is that instance is not receiving information on generic type upon creation. Reason is the NEW bytecode instruction that has a single parameter, which is pointer to a CONSTANT_Class entry in a co
#5 by toku on February 9, 2005 - 12:02 am
Sorry for offtopic…
Why you have a name OTAKU? Do u have jap. origins?
#6 by thefrog on February 9, 2005 - 2:44 am
I believe it just doesn’t matter what type you use on the ‘remove’ signature. It’s valid to try to remove objects that are not in the collection, so what additional safety do you gain from restricting the type of the remove parameter?
#7 by Kyle Lahnakoski on February 9, 2005 - 5:36 am
> so what additional safety do you gain from
> restricting the type of the remove parameter?
To catch brain-farts. I could easily imagine typos (or copied code) that removes the wrong object from a Collection. The static checks could catch most of those problems.
#8 by Tom Hawtin on February 9, 2005 - 1:05 pm
Kyle: It’d restrict the use of wildc?rds in collection generic parameters. I ought to be able to remove an object from a collection, even if the exact type parameter type is unknown.
Something does irritates me, however. Although there is a common idiom that a key that maps to null in a Map is the same as checking if the map contains the key, I can still place null values in a Map if I so wish (given a suitable implementation). But try putting nulls in a Queue. What’s the difference?
#9 by fungus toenail treatment on September 28, 2006 - 8:18 am
big thank