getTypeParameters() will tell you that Map<K,V> is parameterized by K and V and if/how these are contrained by wildcards.
It won't tell you that the Map passed to your method is a Map<String,Foo>, though. Map.class covers the generic notion of Map<K,V> -- it knows nothing about how a particular instance was parameterized and there's no such thing as a Map<String,Foo>.class in terms of this being any different than Map<K,V>. Peter Becker wrote: > Like this: > > > http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getTypeParameters() > > ? > > Peter > > On Wed, Nov 5, 2008 at 2:35 PM, Jess Holle <[EMAIL PROTECTED]> wrote: > >> For the most part, Java 5 class files contain metadata indicating much of >> what the source file indicated as far as generics are concerned. This is >> certainly the case for field/method/class declarations. I'm not sure about >> local variable declarations, though. >> >> That said, once one has something like: >> >> void <T extends Foo> sort( List<T> list ) { ... } >> >> one can only determine that 'list' is parameterized by 'T', any >> extends/super constraints, etc. The body of sort() here has no other >> notions about T -- either in the class file or at runtime. That is >> erasure. List<A>.class == List<B>.class == List.class. This is necessary >> to keep the existing contracts and is a key benefit to erasure -- both in >> lack of class bloat and in preservation of existing contracts and >> compatibility. One could potentially have a special >> Class.getGenericTypeInfos(Object) utility that could seperately lookup this >> info, e.g. by having each object refer to both its class and its generic >> typing info -- rather than to just the class. When called by old, >> non-generic-savvy code the generic typing info would be null, of course. >> One could have the compiler do nifty bits with such a getGenericTypeInfos() >> utility so that one could do things like "new T[]" in sort -- throwing a >> runtime exception if the typing info is not present. This would be undoing >> erasure without blowing new/old code interoperability except where actually >> necessary. >> >> -- >> Jess Holle >> >> Christian Catchpole wrote: >> >> Here is my analysis of the situation. I could be wrong. But here >> goes.. >> >> When I got my copy of Java 5 my first question was, do generics really >> take the cast out of the equation? I disassembled the code to find >> the cast still exists. This implies that when you compile this.. >> >> HashMap<String,String> map = new HashMap<String,String>() >> String string = map.get(""); >> >> The generated code actually equates to this.. >> >> HashMap map = new HashMap() >> String string = (String)map.get(""); >> >> The class returned by map.getClass() does not know the map only >> contains Strings. It's actually the reference to the map which >> marshals the types. >> >> I did a quick test... >> >> HashMap<String,String> map1 = new HashMap<String,String>(); >> HashMap<Date,Date> map2 = new HashMap<Date,Date>(); >> >> System.out.println(map1.getClass() == map2.getClass()); >> >> true >> >> They use the same class and can't therefore hold the type information >> for both declarations. >> >> I can only assume this re-compiler the posse were talking about, scans >> the code for the actual cast / type check to determine the types. >> >> >> >> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ 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 [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
