Re: ArrayList.Iterator.remove()
Kevin McMurtrie wrote:
Lew wrote:
To what insanity do you refer?
Kevin McMurtrie wrote:
Simple generics work fine but all hell breaks loose on complex data. The
solution just isn't very robust. This sums it up well:
http://www.ibm.com/developerworks/java/library/j-jtp01255.html
I don't see insanity here.
Don't even get me started on ReferenceQueue generics.
It also forgets to mention that each genericized method has a
non-genericized method automatically created by the source compiler:
The output of the compiler is generics-free, of course. This is well documented.
class Foo extends HashSet<Integer>{}
class Bar<T> extends HashMap<Integer, T>{}
class Moo<T> extends HashMap<Integer, T>
{
@Override public T put(Integer key, T value)
{
return super.put(key, value);
}
}
new Foo().add("hello"); //Compile Error
Duhhh. That's the purpose of generics.
new Bar<String>().put("hello", "there"); //Compile Error
Duhhh. That's the purpose of generics.
new Bar().put("hello", "there"); //OK... until later.
//Drumroll....
new Moo().put("hello", "there");
//ClassCastException on a bogus line number
Well, duhhh. You used a raw type, which does create a compiler warning. One
is thoroughly advised not to mix raw types and generics. That
ClassCastException is exactly what one would have gotten before generics were
added to Java.
What you illustrate here is not generics insanity but a typical programmer error.
--
Lew