Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.java.programmer > #36527 > unrolled thread

Re: Generics and downcasts

Started byArne Vajhøj <arne@vajhoej.dk>
First post2017-04-24 21:29 -0400
Last post2017-04-24 21:29 -0400
Articles 1 — 1 participant

Back to article view | Back to comp.lang.java.programmer

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Generics and downcasts Arne Vajhøj <arne@vajhoej.dk> - 2017-04-24 21:29 -0400

#36527 — Re: Generics and downcasts

FromArne Vajhøj <arne@vajhoej.dk>
Date2017-04-24 21:29 -0400
SubjectRe: Generics and downcasts
Message-ID<odm8q9$1ihg$1@gioia.aioe.org>
On 4/24/2017 6:23 PM, Stefan Ram wrote:
>   Naftalin and Wadler write that
>
> List<String> words = new ArrayList<String>();
> words.add("Hello ");
> words.add("world!");
> String s = words.get(0)+words.get(1);
> assert s.equals("Hello world!");
>
>   is compiled to the same Bytecode as
>
> List words = new ArrayList();
> words.add("Hello ");
> words.add("world!");
> String s = ((String)words.get(0))+((String)words.get(1))
> assert s.equals("Hello world!");
>
>   and then write:
>
> Cast-iron guarantee: the implicit casts added by the
> compilation of generics never fail.
>
>   This, of course, immediatly leads to the question:
>
>   Since the downcasts added during the compilation of
>   the above generic code can never fail and since they
>   add run-time costs, can't they be omitted?
>
>   Maybe the purpose of these downcasts is to add
>   additional safety for the case of some parts of a
>   program not using generics. (I.e., in the presence of
>   "unchecked" warning.)
>
>   A program might define a /private/ generic class and make
>   sure that /all/ accesses to this class use generics, yet it
>   still has to pay the price of those downcasts!

I think it depends on what level you consider.

source : type safe and no cast required

byte code : due to type erasure then the get actually returns
Object and need to be cast

native code : the JIT compiler may be able to detect there is
no need for an actual type check as part of that cast

Arne

[toc] | [standalone]


Back to top | Article view | comp.lang.java.programmer


csiph-web