Re: an array in a hashtable
At least it shouldn't be too hard to make pmd, checkstyle, your
favourite IDE, etc., flag that up as a dodgy area, calling remove(int)
on a List<Integer>. I'm not sure what you could do about it though, to
shut the checker up. Putting an explicit cast to int in? First
assigning it to a List<?>? Neither seems satisfactory.
Maybe deprecate it and use a static utility method to get at it.
That'd be popular..
I'll be even more careful to avoid overloading in my future APIs.
Nice discussion.
Chris Uppal wrote:
Hendrik Maryns wrote:
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());
}
}
/Very/ nice example.
Although it is the same problem as short conversion to ints. So I don't
consider this a particularly strong argument against autoboxing, but
rather one more against the whole automatic conversion thing.
While I agree that the combination of method overloading and automatic
conversion leads (at least potentially) to confusion, I don't think I'd go so
far as to blame the above example on that. I don't think it would be possible
to achieve the effect of Thomas's masterful indirection without the more
powerful intuition-breaking possibilities of autoboxing.
It would probably be possible to concoct an example which misbehaved as badly
using only the conversions in Java before 1.5, but I think the API would be
obviously artificial. In this case an /existing/, and not obviously crap[*],
API has been broken by autoboxing.
-- chris
[*] a bit dodgy, but not to the point where I remember anyone ever pointing it
out, or complaining about it.