Re: ArrayList.Iterator.remove()
Kevin McMurtrie wrote:
class Moo<T> extends HashMap<Integer, T>
{
@Override public T put(Integer key, T value)
{
return super.put(key, value);
}
}
....
new Moo().put("hello", "there");
//ClassCastException on a bogus line number
....
Regardless of whether classes Moo or Bar are constructed with
generics, the Map key is clearly defined as Integer. The source
compiler added a hidden method that allows compilation of code that can
not run.
It's not a "hidden" method, it's
'public Object put( Object key, Object value )',
as is always the case when you erase generics, and is heavily documented as such.
The 'Map' key is based on extending 'HashMap<Integer, T>', which erases to
'HashMap <Object, Object>', and is therefore not "clearly defined as Integer"
at run time. You call this "insanity", but it's really just plain old simple
erasure. This is the common programmer error to which I alluded upthread, and
the inevitable consequence of mixing raw and generics types. You insert a
'String' key into the map, then try to extract it to an 'Integer' target, thus
yielding the 'ClassCastException', just as documented and expected for this
scenario. Again, this is what would happen if you tried this prior to Java 5.
It makes no sense to break the rules, get the exact result that is documented
for breaking the rules, then complain that you get that result.
--
Lew