Actually guys, referential equality is kind of retarded, so the
Map<String,Integer>.class == Map<Foo,Bar>.class
example is bad.
However,
Map<String,Integer>.class.equals(Map<Foo,Bar>.class) SHOULD return false
On Thu, Nov 6, 2008 at 12:38 AM, Jess Holle <[EMAIL PROTECTED]> wrote:
> Peter Becker wrote:
>
> I think you probably want something like:
>
> Object -> ConcreteClass(String,Foo) -> GenericClass
>
> which adds the extra class instances, but they should be very small
> and not too many.
>
> Alternatively you could do:
>
> Object(String,Foo) -> GenericClass
>
> but then you'd have to store the type parameters on each object, which
> is probably much more expensive in total. The former approach seems to
> also match the type model better.
>
>
> Yes, I was thinking something along the lines of the former.
>
> On Thu, Nov 6, 2008 at 8:22 AM, Jess Holle <[EMAIL PROTECTED]> <[EMAIL
> PROTECTED]> wrote:
>
>
> 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]> <[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()
>
> <http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Class.html#getTypeParameters%28%29>
>
> ?
>
> Peter
>
> On Wed, Nov 5, 2008 at 2:35 PM, Jess Holle <[EMAIL PROTECTED]> <[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.
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> >
>
--
Viktor Klang
Senior Systems Analyst
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
