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.
>
>
>
>
>
>
> >
>
--
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/javaposse?hl=en
-~----------~----~----~----~------~----~------~--~---
