Will generics implementation eliminate runtime casting?

Question

Before generics, one must explicitly cast when pulling out of an iterator. For example:
List l = ...
for(Iterator i = l.iterator(); i.hasNext();) {
doSomethingWithInteger((Integer)l.next());
Now with generics, we won't have to explicitly cast the return value of the iterator's .next() method:
List<Integer> l = ...
for(Iterator i = l.iterator(); i.hasNext();) {
doSomethingWithInteger(l.next());
However, form what I've seen of decompiled code compiled with the beta version of the generics compiler, there is still implicit casting going on. The return value of Iterator.next() is still being casted to an Integer. And runtime casting like this has actual instructions to be executed, not just syntactic sugar. It seems silly to me, though, since everything in the List is an Integer, there should be no need to explicitly cast it.
So will the addition of generics not be able to eliminate this overhead? Why was this decided?

Answer 1

It actually turns out that the runtime casts are extremely cheap to do, because modern superscalars typically have plenty of extra functional units and branch prediction on the cast is extremely accurate (all the casts inserted by JSR-14 are always true, so the branches always predict correctly).
But even though they have a negligible performance cost, they do bloat the binary. The NextGen proposal
http://doi.acm.org/10.1145/286936.286958
was always the "future" solution to this. It's the second step of the implementation. The first step is JSR-14.