Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #4547
| Newsgroups | comp.lang.java.programmer |
|---|---|
| Subject | Re: Java generics and type erasure |
| From | Ian Shef <invalid@avoiding.spam> |
| References | <9d4c2b16-beb5-40b1-87a2-f03e971efeed@k17g2000vbn.googlegroups.com> <nospam-871A48.22542123052011@news.aioe.org> <irfgkl$lca$1@news.albasani.net> |
| Message-ID | <Xns9EEF8515AF3B6vaj4088ianshef@138.125.254.103> (permalink) |
| Date | 2011-05-24 20:04 +0000 |
| Organization | Raytheon Company |
Lew <noone@lewscanon.com> wrote in news:irfgkl$lca$1@news.albasani.net:
> John B. Matthews wrote:
>> Marcin Pietraszek<m.pietraszek@gmail.com> wrote:
<snip>
>
>>> 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.
Correct (although "gives up" is an unfair characterization). One of the
things that I learned recently about generics is that using a raw type
e.g. Foo foo2 = ...
causes the compiler to treat everything within that type as raw (with respect
to the particular variable that was declared with the raw type).
That is, any use of foo will now be treated as if everything within the Foo
class was defined as a raw type. Thus,
private Map<String, Integer> bar = new HashMap<String, Integer>();
now gets treated as if it was written
private Map bar = new HashMap();
Now (as far as the compiler is concerned) foo2.bar.get("x") produces an
Object and not the Integer that one naively might expect.
> 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?
It better be someplace in the JLS but I have not looked. I prefer to use
Angelika Langer's Java Generics FAQs. FAQ_203 says (in part):
"Fields of a raw type have the type that they would have after type erasure."
See
<http://www.angelikalanger.com/GenericsFAQ/FAQSections/ParameterizedTypes.htm
l#FAQ203>
That is somewhat subtle but describes the situation observed here. I have
seen a clearer explanation elsewhere recently but cannot recall where.
Sorry.
>
> 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.
Au contraire. The Java Tutorial says "When a generic type is instantiated,
the compiler translates those types by a technique called type erasure — a
process where the compiler removes all information related to type parameters
and type arguments within a class or method."
See
<http://download.oracle.com/javase/tutorial/java/generics/erasure.html>
I interpret this to mean that type erasure happens at compile time - not at
run time.
>
> The direct dot reference to a 'private' member is a bit dodgy, though
> allowed in the class's own 'main()'.
>
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
Java generics and type erasure Marcin Pietraszek <m.pietraszek@gmail.com> - 2011-05-23 13:18 -0700
Re: Java generics and type erasure "John B. Matthews" <nospam@nospam.invalid> - 2011-05-23 22:54 -0400
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-24 01:45 -0400
Re: Java generics and type erasure Marcin Pietraszek <m.pietraszek@gmail.com> - 2011-05-24 12:39 -0700
Re: Java generics and type erasure Ian Shef <invalid@avoiding.spam> - 2011-05-24 20:04 +0000
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-24 17:06 -0400
Re: Java generics and type erasure Ian Shef <invalid@avoiding.spam> - 2011-05-24 23:05 +0000
Re: Java generics and type erasure Susan Calvin <s.calvin@usr.invalid> - 2011-05-25 00:13 +0000
Re: Java generics and type erasure Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-26 10:18 +1200
Re: Java generics and type erasure Susan Calvin <s.calvin@usr.invalid> - 2011-05-26 01:12 +0000
Re: Java generics and type erasure Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-26 13:59 +1200
Re: Java generics and type erasure Susan Calvin <s.calvin@usr.invalid> - 2011-05-26 04:18 +0000
Re: Java generics and type erasure Lawrence D'Oliveiro <ldo@geek-central.gen.new_zealand> - 2011-05-26 18:48 +1200
Re: Java generics and type erasure Esmond Pitt <esmond.pitt@bigpond.com> - 2011-05-26 18:34 +1000
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-26 07:45 -0400
Re: Java generics and type erasure "John B. Matthews" <nospam@nospam.invalid> - 2011-05-26 15:25 -0400
Re: Java generics and type erasure Esmond Pitt <esmond.pitt@bigpond.com> - 2011-05-27 12:01 +1000
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-26 22:15 -0400
Re: Java generics and type erasure Esmond Pitt <esmond.pitt@bigpond.com> - 2011-05-27 13:04 +1000
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-27 01:27 -0400
Re: Java generics and type erasure Esmond Pitt <esmond.pitt@bigpond.com> - 2011-05-27 18:07 +1000
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-27 10:18 -0400
Re: Java generics and type erasure Andreas Leitgeb <avl@gamma.logic.tuwien.ac.at> - 2011-05-27 17:03 +0000
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-27 13:27 -0400
Re: Java generics and type erasure Esmond Pitt <esmond.pitt@bigpond.com> - 2011-05-30 15:19 +1000
Re: Java generics and type erasure Tom McGlynn <taqmcg@gmail.com> - 2011-05-26 19:53 -0700
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-27 01:30 -0400
Re: Java generics and type erasure Esmond Pitt <esmond.pitt@bigpond.com> - 2011-05-27 18:09 +1000
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-27 10:22 -0400
Re: Java generics and type erasure Esmond Pitt <esmond.pitt@bigpond.com> - 2011-05-30 15:23 +1000
Re: Java generics and type erasure Lew <noone@lewscanon.com> - 2011-05-30 02:35 -0400
csiph-web