Peter Becker wrote:
> Sorry: I missed that parameter in your method.
>
> Wouldn't adding this information lead to a potential explosion of
> Class instances at runtime similar to C++ templates? OTOH: there are
> only a limited number of type parameters you'd actually use in your
> code, so it is probably not too bad -- after all we wouldn't copy the
> whole code as C++ does, just get a construct refering to the generic
> class version and storing the type parameters.
>
Avoding this explosion is a benefit of erasure as well. Dealing with
C++ I quickly had dozens and dozens of copies of the same (sizable)
object code all due to instantiation with different types -- even where
the usage of the types in question (e.g. char*, void*, int*, Foo*, etc,
in a vector<>) ended up being 100% equivalent from an object code
perspective. I don't want to go near that sort of issue again.
That said, I see no reason to have separate Class objects for
Map<String,Foo> and Map<Bar,Baz>. This would lead to bloat and
incompatibility.
Rather one could have something like a "GenericTypesMap", ala:
For class Map<K,V>, Map<String,Foo> would have a GenericTypesMap of
{K->String,V->Foo}
GenericTypesMap's could be shared across all instances which use the
same instantation types and be weakly referenced by them or some such.
I'm clearly just throwing together a strawman here, but the idea is to
have a separate chunk of runtime data that spells out the generic types
used by an instance without (1) breaking of existing Class contracts,
explicit or implicit, (2) resulting in duplication of Class objects or
other bloat, or (3) breaking interoperability between new and old code.
--
Jess Holle
> On Thu, Nov 6, 2008 at 7:47 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
>
>> 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
-~----------~----~----~----~------~----~------~--~---
