Bill: Yes, and no. It's complicated.
Generics could show up in 3 places:
Types, Signatures, and Objects.
Generics are not, are definitely, and are kind of, erased,
respectively, in those 3 places. To be specific:
Generics information from TYPES is not, and has never been, erased. If
you write:
public List<String> foobar; //this is a field.
then the fact that foobar is a List<String> is available in the class
file, and even available via reflection if you use the right methods
(which are admittedly very awkward, but you can get it with some
effort).
Generics information from SIGNATURES is erased.
If you write:
public void foobar(List<String> x) {}
public int foobar(List<Integer> x) {}
javac will not even compile it, eventhough normally 2 methods with
different parameter lists are separate even if they share a name.
That's because internally, generics isn't encoded in a method
signature. In java, method names are expanded with their parameter and
return type, so the above would become:
com.package.ContainingClass.foobar(Ljava/util/List;V)
com.package.ContainingClass.foobar(Ljava/util/List;I)
which is not okay - being only different in return type is not
allowed. This isn't a big concern and is not generally covered by what
is meant with 'we should reify generics', but its important to know
that this can pretty much never be fixed without serious overhauling
of the JVM.
Generics information from OBJECTS is erased, but this is a JVM thing:
If you write:
new ArrayList<String> foobar;
then what actually happens is that you just create an ArrayList. Yes,
javac does not encode the <String> part of it in the classfile (you
couldn't even if you wanted to; you can't put annotations there and
there's no JVM directive to state generics parameters when
constructing an object), but other than this lack of encoding
parameters when calling methods / constructors, the JVM is perfectly
free, in a future version, to start tracking this stuff. For example,
in the statement:
List<String> foo = new ArrayList<String>();
what can actually be recovered by the JVM at runtime is this:
List<String> foo = new ArrayList();
In that situation, the only possible legal construction that can show
up on the right hand side is <String>, so a future JVM could in theory
attach this to the object instance and make that "String" relation
retrievable via a new addition to the reflection API. Things get more
difficult in situations like:
List<? super Double> foo = new ArrayList<Number>();
Here the compiler really can't infer the 'Number' on the RHS from the
generics signature on the LHS (which is the only thing a java v1.5 or
1.6 class file carries inside it) - it knows it has to be either
Number, or Double, or Object, or Serializable. Those are the only four
options. But which one of those is it?
This boils down to objects not being part of the class file
architecture; objects are created by the runtime itself. Class files
merely contain the code that explains to the runtime how and when to
create them. So, the answer for this last one is 'it's complicated'.
On Jan 14, 3:39 pm, Bill Robertson <billrobertso...@gmail.com> wrote:
> I can see that for "obsolete" libraries, but I have trouble seeing
> that happening for reified generics. Don't reified generics start at
> compile time? i.e. is the type erasure is done by javac? If so, I
> don't see how a modular runtime could help.
>
> On Jan 12, 8:27 am, Jess Holle <je...@ptc.com> wrote:
>
> > Weiqi Gao wrote:
> > > Now that the Java 7 feature set has been redefined and (provisionally
> > > and non-bindingly) finalized (again), and my (and I think a lot of
> > > others') favorite features are not in it, I think it's time to start
> > > compile a wish list for Java 8 and Java 9.
>
> > > Here's mine:
>
> > > Java 8:
>
> > > Reified generics
> > > Removal of dead features (java.awt.Button, etc.)
>
> > A large benefit of modularization ala Jigsaw is that you don't have to
> > remove stuff like this (which you really can't without breaking a lot of
> > applications). Instead it goes into an obsolete/deprecated module which
> > you just never load if you don't use it.
>
> > Ideally Javadoc gets updated to hide such cruft by default as well.
>
> > Then you get the best of both worlds -- nothing breaks, but you don't
> > have to pay for cruft in any real sense.
>
> > --
> > Jess Holle
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "The
Java Posse" group.
To post to this group, send email to javaposse@googlegroups.com
To unsubscribe from this group, send email to
javaposse+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
