Prev: Java and awk (jawk)
Next: Possible easy diagnostic outputting from multiple threads tothe one text frame
From: Kevin McMurtrie on 7 Jul 2010 12:28
In article <i11nnc$udp$1(a)news.albasani.net>, Lew <noone(a)lewscanon.com>
wrote:

> Kevin McMurtrie wrote:
> >> [...]
> >> public class Foo<BAR>
> >> {
> >> class InnerFoo { }
> >> void method ()
> >> {
> >> InnerFoo x[]= new InnerFoo[100]; //Doesn't compile
> >> }
> >> }
>
> Peter Duniho wrote:
> > I'd guess the answer to that may actually be specifically addressed in
> > the spec too.
> >
> > But even if not, it seems to me that your example is just a variant on
> > the situation that's already being discussed. The above version of the
> > code involves a non-reified generic type (Foo<BAR>.InnerFoo), of which
> > you can't make an array, and for the same reason as indicated before.
> >
> > By explicitly choosing the raw type to qualify InnerFoo, you strip the
> > generic and thus create a legal array type. Note that while the third
> > example compiles, you do get a warning about the need for an unchecked
> > conversion. That's only slightly better than it simply not compiling at
> > all.
>
> I wonder if a non-inner nested class member would have this trouble. I also
> wonder if
> InnerFoo x[] = new this.InnerFoo [100];
> or something along those line would work.
>
> I'll try that later myself, along with variations for a local class (which I
> expect not to). One wonders about inner classes in a static context, albeit
> less so.
>
> I've been shot down in this forum before for he suggestioon that an
> inner-class definition belongs to a particular enclosing-class instance (as
> opposed to the inner-class *instance* belonging to an instance), and there
> definitely are limits to that mental model, but it works out to be a handy
> way
> to look at things most times.


Eclipse says "new this.InnerFoo [100]" doesn't compile. You can use
"(InnerFoo[])Array.newInstance(InnerFoo.class, 100)"

The annoying thing about the example that I gave is that the declaration
of the array works fine. There's nothing special about allocating the
array that should make it any different when Generics are involved.

Java Generics are a handy tool but the implementation is flawed enough
that I can see it hindering future language improvements. I would have
preferred something like C++ templates even if it meant redoing a lot of
the java.util package. Besides being more powerful, it would eliminate
the need for horribly inefficient autoboxing of short, char, int, long,
float, and double.
--
I won't see Google Groups replies because I must filter them as spam
From: Lew on 7 Jul 2010 12:56
Kevin McMurtrie wrote:
> The annoying thing about the example that I gave is that the declaration
> of the array works fine.  There's nothing special about allocating the
> array that should make it any different when Generics are involved.
>

Other than the reason the JLS gives, you mean. The "something
special" is mentioned there.

--
Lew

From: Mike Schilling on 7 Jul 2010 18:27


"Lew" <lew(a)lewscanon.com> wrote in message
news:e73f0c28-0e8d-43c4-a786-045852b83bc6(a)q16g2000vbd.googlegroups.com...
> Lew wrote:
>>> Arrays and generics don't mix. It has to do with arrays being
>>> reifiable but not generics.
>>
>>> From the JLS, 10.10:
>>> "... creation of arrays of non-reifiable types is forbidden."
>>> <http://java.sun.com/docs/books/jls/third_edition/html/
>>> arrays.html#10.10>
>>
>
> Mike Schilling wrote:
>> There aren't many instances in Java of "That's how it works. Don't ask
>> why;
>> you're better off not knowing", but this is one of them.- Hide quoted
>> text -
>>
>
> It's funny you should say that, because the JLS says why in the
> section I cited.

Oh, I know why, I just wish I didn't. :-)

First  |  Prev  | 
Pages: 1 2 3
Prev: Java and awk (jawk)
Next: Possible easy diagnostic outputting from multiple threads tothe one text frame