Heh, I fell for that one. I was expecting 1, and half expecting 2, and
to discover that Integer.equals or hashCode was broken..
That's more of an issue with overloading. When remove(int) and
remove(Integer) are available, Java will pick int if it can, the
closest match.
That is not a fault of generics, but of the collections APIs, and
possibly of Java, allowing overloading at all (beyond the scope of
this).
You might as well avoid arrays of reference types, yes, because they
are statically broken in Java (but sound at runtime).
Integer[] ints={1,2,3};
Number[] numbers=ints;
number[0]=6.0; //ArrayStoreException, the runtime catches what the
compiler doesn't.
The problem with generics and reference types is that, because arrays
are statically broken, the runtime needs to know the type of an array.
Because generics are not statically broken, the runtime doesn't need to
know the generic type parameter. I'm rather surprised that there is
nothing like Array.newInstance, but that returns a T[] instead of
Object. Maybe there is and I missed it, but Angelika Langer doesn't
mention anything..
http://www.angelikalanger.com/Articles/Papers/JavaGenerics/ArraysInJavaGenerics.htm
Thomas Hawtin wrote:
ricky.clarkson@gmail.com wrote:
With generics, this is fairly straightforward, despite Chris Uppal's
misgivings:
Map<Integer,int[]> map=new HashMap<Integer,int[]>();
map.put(11,new int[]{2,3,3,2});
map.get(11)[2]=5;
It's probably arrays of generic types that Chris was thinking about.
With generics, you might as well avoid arrays of all reference types.
The other worrying thing is that auto[un]boxing can behave a little
strangely. For instance the following code:
class Box {
public static void main(String[] args) {
java.util.List<Integer> list =
new java.util.ArrayList<Integer>();
list.add(1001);
list.add(1002);
list.remove(1001);
System.out.println(list.size());
}
}
Guess what it prints, and then try it.
Tom Hawtin
--
Unemployed English Java programmer
http://jroller.com/page/tackline/