Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!news.albasani.net!.POSTED!not-for-mail
From: Lew <noone@lewscanon.com>
Newsgroups: comp.lang.java.programmer
Subject: Re: Java generics and type erasure
Date: Tue, 24 May 2011 01:45:12 -0400
Organization: albasani.net
Lines: 90
Message-ID: <irfgkl$lca$1@news.albasani.net>
References: <9d4c2b16-beb5-40b1-87a2-f03e971efeed@k17g2000vbn.googlegroups.com> <nospam-871A48.22542123052011@news.aioe.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Trace: news.albasani.net Ysg05np6w1dYjy9rcSxWI0QyhkugLwIkwdp3jkZ1gSymbLdPEBFatJvCu8fMIqQBJ/EEJ3anCaDaYAXMUKB1PcGWlPMXiLfQ5YCNuwRJJA4hboRSECTRI5KNGeEDXy3C
NNTP-Posting-Date: Tue, 24 May 2011 05:44:53 +0000 (UTC)
Injection-Info: news.albasani.net; logging-data="iYS0TzWW2KSPCn87N/eEMGXjumJd49CCZxXHbVSMpLr3xsk5Tev5Cvo6E/x/M2yW5PyjKcTcxSCOtQPcirlh47vKSWqREHsr2IfLC6gP7TRUEmqMJ33TelfbZLzt8n/3"; mail-complaints-to="abuse@albasani.net"
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
In-Reply-To: <nospam-871A48.22542123052011@news.aioe.org>
Cancel-Lock: sha1:uWpiFD+Hbby/gs8qYJjE5Btvq2E=
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:4514

John B. Matthews wrote:
> Marcin Pietraszek<m.pietraszek@gmail.com>  wrote:
>
>> Some time ago I've encountered stange behaviour while using generics,
>> small example is provided in gist:
>>
>> https://gist.github.com/977599

You should post the code in the message instead of out of band.

import java.util.*;

public class Foo<T> {

     private Map<String, Integer> bar = new HashMap<String, Integer>();

     public static void main(String ... args) {
         Foo<Boolean> foo1 = new Foo<Boolean>();
         Integer x1 = foo1.bar.get("x"); // ok

         Foo foo2 = new Foo<Boolean>();
         Integer x2 = foo2.bar.get("x"); // compilation failure
     }

}

>> Anybody could explain me why in second example (line commended with
>> "compilation failure") compilation fails?

> You neglected to specify the type parameter for foo2, specified in the
> declaration Foo<T>. Without the actual type,<Boolean>, the compiler
> can only infer that get() returns Object, as would have been the case
> prior to generics:
>
> import java.util.*;
>
> public class Foo<T>  {
>
>      private Map<String, Integer>  bar = new HashMap<String, Integer>();
>
>      public static void main(String... args) {
>          Foo<Boolean>  foo1 = new Foo<Boolean>();
>          Integer x1 = foo1.bar.get("x"); // ok
>
>          Foo<Boolean>  foo2 = new Foo<Boolean>();
>          Integer x2 = foo2.bar.get("x"); // compilation failure
>      }
>
>> Do you know any detailed description on how and when type erasure
>> works in java?

> "All of these parameterized types share the same class at runtime."
>
> <http://java.sun.com/docs/books/jls/third_edition/html/classes.html#8.1.2>
>
> See also, Bloch, ch. 5:
>
> <http://java.sun.com/docs/books/effective/>

It's subtler than that.  The generic parameter is on 'Foo', not the map.  The 
map type does not depend on the type parameter.  So the question is why the 
'get()' returns 'Object'.  Naively, one would expect the type of 'bar' to 
resolve to 'Map<String, Integer>' no matter what '<T>' is, or isn't.

The only thing I can think of is that leaving the type parameter out in the 
containing class means that all bets are off, and the compiler gives up on 
generics throughout that variable's depth.  Thus it doesn't even bother to 
parse the 'bar' parameters, defaulting thus to '<?,?>'.  Consequently, the 
type of the expression 'foo2.bar.get("x")' is 'Object'.  The assignment target 
of that expression is 'Integer', and that requires an explicit downcast, 
omitted in the code along with the type parameter.

This is an object lesson (pun intended) in how bad it really can be to omit 
the type parameter.

I haven't looked up chapter and verse on this reasoning yet.  Anyone care to 
rise to the challenge?

A couple of observations:

Type erasure has absolutely nothing to do with this.  Type erasure happens at 
run time.  It will never create a compiler error.

The direct dot reference to a 'private' member is a bit dodgy, though allowed 
in the class's own 'main()'.

-- 
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg