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 [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
-~----------~----~----~----~------~----~------~--~---
