On the type level you also have the problems that 1) you can't implement two interfaces which differ only in their type parameter, e.g. you can't be Comparable<String> and Comparable<Date> (I had sensible examples, but I forgot them). This relates to the signature problem in some ways, but the two methods you would need to implement in the example are actually a legal overload.
2) you can't do "T.class" in a MyClass<T> (http://www.angelikalanger.com/GenericsFAQ/FAQSections/TypeParameters.html#FAQ206). You can do a magic incantation to get that information ((Class<T>) ((ParameterizedType) this.getClass().getGenericSuperclass()).getActualTypeArguments()[0]), but that's pretty weird and also breaks if you suddenly get wrapper objects (e.g. you can't write a generic JPA Dao if you want to use Spring's transaction mechanisms since they use AOP wrappers). That's when you start passing a Class<T> as extra parameter, which is confusing for ~100% of developers and it always means your API suddenly gets warts. Peter On Thu, Jan 15, 2009 at 1:28 AM, Reinier Zwitserloot <reini...@gmail.com> wrote: > > 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 > > > -- What happened to Schroedinger's cat? My invisible saddled white dragon ate it. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
