Java generics and type erasure

[Lew]

Perhaps the confusion here may be due to an ambiguity in the phrase
'generics are erased to ... at runtime'
which I could interpret in two ways. It can mean the something is
actively erasing them at runtime, or it can mean that they have the
static characteristic of having been erased to xxx at runtime. The
first would suggest that type erasure is happening at runtime while
the later implies that erasure has already happened, i.e., at compile
time. While I gather you intended the later, I think someone
inferring the former has a reasonable case too.

I had just finished making essentially the same point moments before I read
your post. Yes, that's the way I mean it - it's not the process of erasure
that interests me, but the static state of having or not having been erased.
Not erased - compile time. Erased - runtime. Therefore erasure (the way I
look at it) is a runtime phenomenon. I don't care if it happened during
compilation or class load.

 

[Esmond Pitt]

The meaning of the assertion you cite was that the generics information
that is present in the bytecode is ignored at runtime

No. There is no generic information in the bytecode to ignore. It has
been erased by the compiler. The only generic information in the .class
file is in the method signatures, and they are there for the compiler,
not for the JVM.

 

[Esmond Pitt]

erasure (the way I look at it) is a runtime phenomenon. I don't care if
it happened during compilation or class load.

That doesn't make sense. Erasure is a state that has already been
attained prior to execution. It can't be a runtime phenomenon as there
hasn't been any runtime yet: indeed there may never be a runtime for it
to be a phenomenon of, e.g. if the class is immediately recompiled prior
to any execution, or indeed never executed at all.

 

[Lew]

No. There is no generic information in the bytecode to ignore. It has been
erased by the compiler. The only generic information in the .class file is in
the method signatures, and they are there for the compiler, not for the JVM.

OK, so I shouldn't have said "bytecode", I should've said "class file", two
terms that I treat interchangeably. It's in the freaking CLASS FILE, right?
Isn't that the thing that gets used at runtime? Doesn't the generic
information in THE CLASS FILE get ignored at runtime just like I said?

SO it IS a runtime phenomenon that the generic information IN THE CLASS FILE
is ignored.

Better?

 

[Lew]

That doesn't make sense. Erasure is a state that has already been attained
prior to execution. It can't be a runtime phenomenon as there hasn't been any
runtime yet: indeed there may never be a runtime for it to be a phenomenon of,
e.g. if the class is immediately recompiled prior to any execution, or indeed
never executed at all.

You elided the part of my statement that answers your objection.

What I *SAID* that you chopped out was:


"... it's not the process of erasure that interests me, but the static state
of having or not having been erased. Not erased - compile time. Erased -
runtime. Therefore erasure (the way I look at it) is a runtime phenomenon. I
don't care if it happened during compilation or class load."

It makes perfect sense. You will note that I did NOT say that which you
refuted; I did NOT say that it got erased at runtime. I said that the runtime
phenomenon is the static state of generics HAVING ALREADY BEEN ERASED SOMETIME
*PRIOR*. It's the *static* state to which I refer. See, Esmond Pitt?

You did not contradict that at all, Esmond Pitt.

Get it now, Esmond Pitt?

 

[Andreas Leitgeb]

OK, so I shouldn't have said "bytecode", I should've said "class file", two
terms that I treat interchangeably. It's in the freaking CLASS FILE, right?
Isn't that the thing that gets used at runtime? Doesn't the generic
information in THE CLASS FILE get ignored at runtime just like I said?

It's not so much a question of whether the generic information of a
class file (like java/util/ArrayList.class) is used or not, but rather
whether the generic information of a particular *use* of that class was
in the *using* code's class-file, which I think isn't:
... = new ArrayList<ArrayList<ArrayList<Boolean>>>();

 

[Lew]

It's not so much a question of whether the generic information of a
class file (like java/util/ArrayList.class) is used or not, but rather
whether the generic information of a particular *use* of that class was
in the *using* code's class-file, which I think isn't:
... = new ArrayList<ArrayList<ArrayList<Boolean>>>();

Ah, gotcha.

To eliminate my inverted way of expressing it, then, generics effectively
don't exist at runtime because erasure occurs before runtime. Generics errors
occur at compilation. Exceptions not prevented by the generics checks at
compilation occur at runtime, just as they would have were generics never
used, because at runtime the erasure has already occurred and the generics
information effectively no longer exists (but for some non-relevant classfile
information).

Thank you all for helping to clarify this.

 

[Esmond Pitt]

Esmond Pitt wrote:
SO it IS a runtime phenomenon that the generic information IN THE CLASS
FILE is ignored.

Better?

Not even different. The type information present in the source code is
not present in the byte code. It is erased by the compiler. Ergo that
happens at compile time. The compiler puts type information elsewhere in
the class file for its own use, also at compile time. There is no
runtime action anywhere here. Absence of a phenomenon isn't itself a
phenomenon.

 

[Esmond Pitt]

I said that the
runtime phenomenon is the static state of generics HAVING ALREADY BEEN
ERASED SOMETIME *PRIOR*. It's the *static* state to which I refer.

That static state is created at compile time. It exists prior to
runtime. Runtime may never occur. Ergo it doesn't make any sense to
regard it as a runtime phenomenon. Ontologically speaking.

 

[Lew]

That static state is created at compile time. It exists prior to runtime.
Runtime may never occur. Ergo it doesn't make any sense to regard it as a
runtime phenomenon. Ontologically speaking.

Generics don't matter at runtime. They matter at compile time. That's that.