Re: ArrayList.Iterator.remove()
Lew wrote:
charlesbos73 wrote:
erasure? (say as opposed to the way they're done in C#),
Mayeul wrote:
Point taken I guess. No erasure would have horribly broken Java 1.4 code
and previous, so it is necessary. Still, it is a flaw.
While there are definitely times when having generics information at
run time would help, the fact that it's compile-time only does benefit
in that it forces one to handle type issues at compile time, when bugs
are much cheaper to fix than at run time.
Yes, compile-time checking is Good. But it doesn't follow that
run-time checking in addition to compile-time checking would be Bad.
In practice, the need for
run-time generification is only for corner cases; most of the time
it's completely sufficient to have only compile-time checking.
Some of the corners are fairly gently rounded, as witness the
number of questions that arise here about them. Perhaps the two
most common "smooth corners" are constructing instances of and
making arrays of the parameterized type:
class Generic<T> {
T instance = new T(); // no good
T[] array = new T[42]; // no good
}
People misunderstand the generics mechanism. Generics support type
analysis, and type analysis can be quite tricky. Hence, use of
generics can be tricky.
A-men, brother! I recall that when generics first came along
I decided I'd retrofit them into some of my existing code that used
Object references and a lot of casts. NetBeans 3.mumble kept drawing
squiggly red lines under usages I thought were valid, and I simply
couldn't comprehend what was wrong. I tried a javac compilation from
the command line in the faint hope of getting a more comprehensible
diagnostic, and lo! javac accepted my code happily!
NetBeans 5.mumble continued to protest my acceptable-to-javac
code, and it wasn't until NB 6 came along that the squiggly lines
finally went away. If even the tools developers can't get generics
right, what hope is there for mere mortals?
I see no way in which Java violates object orientation except perhaps
the support for static members. [...]
Some have disparaged its use of non-objectified primitive types.
Zealotry is its own reward, I guess.
--
Eric.Sosman@sun.com