That's neat. However, I don't know about others, but my issue with erasure is not that it's cumbersome or somtimes impossible to introspect, but how it exposes a handicap right there in the type- system preventing me from writing certain kinds of code. Imagining something you wish to have implement both Comparable<Salary> and Comparable<Ego>, or say you wish to avoid manual checks and branching by having the type-system help you delegate between PropertyChangeListener<MyJFrame> and PropertyChangeListener<MyOtherJFrame>. That's possible and highly useful in similar languages which does not use erasure.
/Casper On Dec 16, 7:32 pm, "d.j.hagberg" <[email protected]> wrote: > There was an excellent post by Kohsuke today on java.net that talks > about how to use the java.lang.reflect.Type class to introspect > generics and write code that can handle signatures of List<String> vs. > List<Integer> correctly. > > I think this answers the question of how javac, jaxb, and other > utilities handle generics - even though there is type erasure for > backwards compatibility, there is still enough signature in the .class > files to get at this info: > > http://weblogs.java.net/blog/kohsuke/archive/2008/12/introspecting_g.... > > Very, very cool. > -=- D. J. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
