Java generic issue in array

Discussion in 'Java' started by jacksu, May 25, 2006.

  1. jacksu

    jacksu Guest

    I could create:

    ArrayList<Node> myarr = new ArrayList<Node>();

    but can't

    ArrayList<Node> myarr[] = new ArrayList<Node>[n];
    I got error "Cannot create a generic array of ArrayList<Node>

    any suggsetion?

    Thanks.
    jacksu, May 25, 2006
    #1
    1. Advertising

  2. jacksu

    Guest

    generic array creation is not allowed.Try following work-around.

    ArrayList<Node>[] myarr = (ArrayList<Node>[])
    Array.newInstance(ArrayList.class,n);

    jacksu wrote:
    > I could create:
    >
    > ArrayList<Node> myarr = new ArrayList<Node>();
    >
    > but can't
    >
    > ArrayList<Node> myarr[] = new ArrayList<Node>[n];
    > I got error "Cannot create a generic array of ArrayList<Node>
    >
    > any suggsetion?
    >
    > Thanks.
    , May 25, 2006
    #2
    1. Advertising

  3. <> wrote in message
    news:...
    > generic array creation is not allowed.Try following work-around.
    >
    > ArrayList<Node>[] myarr = (ArrayList<Node>[])
    > Array.newInstance(ArrayList.class,n);


    Eh?

    What in the world is that?

    I think the more common way is (at least what I have seen):

    Where n is some integer:

    ArrayList<Node>[] myarr = new ArrayList[n];
    for(int i=0;i<n;i++)
    myarr = new ArrayList<Node>(); //initialize each individually

    --
    LTP

    :)
    Luc The Perverse, May 25, 2006
    #3
  4. jacksu

    Guest

    Well, with my approach you won't get any warning. With yours, you will
    see one warning and to suppress it you have to specify
    @SuppressWarnings("unchecked") annotation.

    :)
    , May 25, 2006
    #4
  5. jacksu

    Chris Smith Guest

    <> wrote:
    > Well, with my approach you won't get any warning. With yours, you will
    > see one warning and to suppress it you have to specify
    > @SuppressWarnings("unchecked") annotation.
    >
    > :)


    Didn't you mean that the other way around? Casting from Object (the
    return type of Array.newInstance) to ArrayList<Node>[] ought to result
    in an unchecked cast warning. Nothing in Luc's response seemed to
    require this warning.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, May 25, 2006
    #5
  6. "Chris Smith" <> wrote in message
    news:...
    > <> wrote:
    >> Well, with my approach you won't get any warning. With yours, you will
    >> see one warning and to suppress it you have to specify
    >> @SuppressWarnings("unchecked") annotation.
    >>
    >> :)

    >
    > Didn't you mean that the other way around? Casting from Object (the
    > return type of Array.newInstance) to ArrayList<Node>[] ought to result
    > in an unchecked cast warning. Nothing in Luc's response seemed to
    > require this warning.



    Luc's

    ArrayList<Node>[] myarr = new ArrayList[n];

    causes a warning:

    Warnings.java:8: warning: [unchecked] unchecked conversion
    found : java.util.ArrayList[]
    required: java.util.ArrayList<java.lang.String>[]
    ArrayList<String>[] myarr = new ArrayList[12];
    Mike Schilling, May 25, 2006
    #6
  7. jacksu

    Chris Smith Guest

    Mike Schilling <> wrote:
    > ArrayList<Node>[] myarr = new ArrayList[n];
    >


    Yep, you're right. I picked up that confusion from an early version of
    the Eclipse generics compiler. It appears that nkalagarla also did the
    same, since the warning from his/her post was apparently missing in
    Eclipse up to 3.2M6, and fixed there. With the current 3.2 milestone,
    both options correctly give warnings.

    That'll teach me to read the spec before replying with something I don't
    understand. :)

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, May 25, 2006
    #7
  8. jacksu

    Tony Morris Guest

    "jacksu" <> wrote in message
    news:...
    >I could create:
    >
    > ArrayList<Node> myarr = new ArrayList<Node>();
    >
    > but can't
    >
    > ArrayList<Node> myarr[] = new ArrayList<Node>[n];
    > I got error "Cannot create a generic array of ArrayList<Node>
    >
    > any suggsetion?
    >
    > Thanks.
    >


    You cannot do that.
    Ponder the thought: you cannot write a 1.5 java.util.ArrayList
    implementation without generating a compile-time warning. Some say generics
    are broken, others (fewer) say arrays are broken - it's all guff on top of a
    flawed premise though.

    --
    Tony Morris
    http://tmorris.net/
    Tony Morris, May 26, 2006
    #8
  9. jacksu wrote:
    > I could create:
    >
    > ArrayList<Node> myarr = new ArrayList<Node>();
    >
    > but can't
    >
    > ArrayList<Node> myarr[] = new ArrayList<Node>[n];
    > I got error "Cannot create a generic array of ArrayList<Node>


    Don't use arrays of references...

    Instead use:

    List<List<Node>> nodeLists = new ArrayList<List<node>>();

    IIRC, the Joshua Bloch's Effective Java Reloaded session at JavaONE
    covered that sort of thing. </appeal-to-authority>

    Alternatively add a class for the concept of the particular use of a
    List of Nodes:

    class NodeString {
    private final List<Node> nodes;
    }
    ....
    List<NodeString> nodeStrings = new ArrayList<NodeString>();

    Tom Hawtin
    --
    Unemployed English Java programmer
    http://jroller.com/page/tackline/
    Thomas Hawtin, May 26, 2006
    #9
  10. "Tony Morris" <> wrote in message
    news:WHsdg.10755$...

    > Ponder the thought: you cannot write a 1.5 java.util.ArrayList
    > implementation without generating a compile-time warning. Some say
    > generics are broken, others (fewer) say arrays are broken - it's all guff
    > on top of a flawed premise though.


    Nitpick: you can do it in later versions of 1.5 by using an annotation that
    specifically turns that warning off. Only a slight improvement, I agree.
    Mike Schilling, May 26, 2006
    #10
  11. "Chris Smith" <> wrote in message
    news:...
    > Mike Schilling <> wrote:
    >> ArrayList<Node>[] myarr = new ArrayList[n];
    >>

    >
    > Yep, you're right. I picked up that confusion from an early version of
    > the Eclipse generics compiler. It appears that nkalagarla also did the
    > same, since the warning from his/her post was apparently missing in
    > Eclipse up to 3.2M6, and fixed there. With the current 3.2 milestone,
    > both options correctly give warnings.
    >
    > That'll teach me to read the spec before replying with something I don't
    > understand. :)


    If you're implying that you'd understand it after you read the spec, it must
    be a better-written spec than the ones I've seen.
    Mike Schilling, May 28, 2006
    #11
  12. jacksu

    Chris Smith Guest

    JLS Interpretation (was Re: Java generic issue in array)

    Mike Schilling <> wrote:
    > If you're implying that you'd understand it after you read the spec, it must
    > be a better-written spec than the ones I've seen.


    Well, no, but understanding specs is not impossible -- just an acquired
    skill. I would have said "yes" until the third edition came out.
    Generics, though, complicate the specification even more than the
    language.

    Here's what I'm seeing here doesn't lead to the conclusion I expected,
    though. Perhaps someone can clarify. The expression in question was:

    ArrayList<Node>[] arr = new ArrayList[n];

    Eclipse and javac both compile this but give a warning about unchecked
    conversion.

    5.2 (Assignment Conversion) says that we have two options for the
    assignment conversion. We should apply (among other irrelevant things)
    widening reference conversion to convert the type ArrayList[] to
    ArrayList<Node>[] first. If that's not possible, we should apply
    unchecked conversion to do so.

    5.1.5 (Widening Reference Conversions) says that widening primitive
    conversion is only possible if the type ArrayList[] is a subtype of
    ArrayList<Node>[].

    4.10.3 (Subtyping among Array Types) says that ArrayList[] is a subtype
    of ArrayList<Node>[] if and only if ArrayList is a subtype of
    ArrayList[].

    4.10.2 (Subtyping among Class and Interface Types) says that
    ArrayList<Node> is a subtype of ArrayList, but NOT vice versa. So we've
    failed.

    Back to 5.2 (Assignment Conversion), the next option is to apply
    unchecked conversion from ArrayList[] to ArrayList<Node>[]. This only
    applies if ArrayList[] is a raw type.

    4.8 (Raw Types) makes ArrayList[] NOT a raw type, even though its
    component type is a raw type. Therefore we can't apply unchecked
    conversion.

    So it seems that the code above should actually fail to compile. Yet it
    does compile. To make that correct, it would seem that it would be
    necessary to expand the definition of unchecked conversion in 5.1.9 to
    include the rule that if an unchecked conversion exists from T to S,
    then an unchecked conversion exists from T[] to S[], and then to update
    text in sections like 5.2 to remove the requirement (which is
    unnecessary anyway) that unchecked conversion is only applied to raw
    types.

    Anyone disagree? What am I missing?

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, May 28, 2006
    #12
  13. Re: JLS Interpretation (was Re: Java generic issue in array)

    "Chris Smith" <> wrote in message
    news:...
    > Mike Schilling <> wrote:
    >> If you're implying that you'd understand it after you read the spec, it
    >> must
    >> be a better-written spec than the ones I've seen.

    >
    > Well, no, but understanding specs is not impossible -- just an acquired
    > skill. I would have said "yes" until the third edition came out.
    > Generics, though, complicate the specification even more than the
    > language.


    Exactly my point. The second edition has some complications (the worst I
    can recall offhand being the rules for resolving method overloads), but they
    can be mastered with a bit of study. This remains true for the 1.5
    additions to the language other than generics. Geenrics are explained in a
    way that does not answer a large number of questions, which then have to be
    resolved by trying things and wondering if javac implements the spec
    correctly.
    Mike Schilling, May 28, 2006
    #13
  14. jacksu

    Dale King Guest

    Re: JLS Interpretation (was Re: Java generic issue in array)

    Chris Smith wrote:
    > Mike Schilling <> wrote:
    >> If you're implying that you'd understand it after you read the spec, it must
    >> be a better-written spec than the ones I've seen.

    >
    > Well, no, but understanding specs is not impossible -- just an acquired
    > skill. I would have said "yes" until the third edition came out.
    > Generics, though, complicate the specification even more than the
    > language.
    >
    > Here's what I'm seeing here doesn't lead to the conclusion I expected,
    > though. Perhaps someone can clarify. The expression in question was:
    >
    > ArrayList<Node>[] arr = new ArrayList[n];
    >
    > Eclipse and javac both compile this but give a warning about unchecked
    > conversion.
    >
    > 5.2 (Assignment Conversion) says that we have two options for the
    > assignment conversion. We should apply (among other irrelevant things)
    > widening reference conversion to convert the type ArrayList[] to
    > ArrayList<Node>[] first. If that's not possible, we should apply
    > unchecked conversion to do so.
    >
    > 5.1.5 (Widening Reference Conversions) says that widening primitive
    > conversion is only possible if the type ArrayList[] is a subtype of
    > ArrayList<Node>[].
    >
    > 4.10.3 (Subtyping among Array Types) says that ArrayList[] is a subtype
    > of ArrayList<Node>[] if and only if ArrayList is a subtype of
    > ArrayList[].
    >
    > 4.10.2 (Subtyping among Class and Interface Types) says that
    > ArrayList<Node> is a subtype of ArrayList, but NOT vice versa. So we've
    > failed.
    >
    > Back to 5.2 (Assignment Conversion), the next option is to apply
    > unchecked conversion from ArrayList[] to ArrayList<Node>[]. This only
    > applies if ArrayList[] is a raw type.
    >
    > 4.8 (Raw Types) makes ArrayList[] NOT a raw type, even though its
    > component type is a raw type. Therefore we can't apply unchecked
    > conversion.
    >
    > So it seems that the code above should actually fail to compile. Yet it
    > does compile. To make that correct, it would seem that it would be
    > necessary to expand the definition of unchecked conversion in 5.1.9 to
    > include the rule that if an unchecked conversion exists from T to S,
    > then an unchecked conversion exists from T[] to S[], and then to update
    > text in sections like 5.2 to remove the requirement (which is
    > unnecessary anyway) that unchecked conversion is only applied to raw
    > types.


    I think the problem is that last step where you say that ArrayList[] is
    not a raw type.

    4.8 says:

    "To facilitate interfacing with non-generic legacy code, it is also
    possible to use as a type the erasure (§4.6) of a parameterized type
    (§4.5). Such a type is called a raw type."

    4.6 on type erasure says: "The erasure of an array type T[] is |T|[]".
    Where |T| means the erasure of T.

    So ArrayList[] is a type erasure of ArrayList< T >[] and a raw type.

    I think the confusion may be the use of the word "name" in section 4.8.
    In reality ArrayList[] is "the name of a generic type declaration used
    without any accompanying actual type parameters".



    --
    Dale King
    Dale King, May 30, 2006
    #14
  15. jacksu

    Chris Smith Guest

    Re: JLS Interpretation (was Re: Java generic issue in array)

    <Dale King <"DaleWKing [at]gmail [dot] com">> wrote:
    > > 4.8 (Raw Types) makes ArrayList[] NOT a raw type, even though its
    > > component type is a raw type. Therefore we can't apply unchecked
    > > conversion.


    > I think the problem is that last step where you say that ArrayList[] is
    > not a raw type.
    >
    > 4.8 says:
    >
    > "To facilitate interfacing with non-generic legacy code, it is also
    > possible to use as a type the erasure (§4.6) of a parameterized type
    > (§4.5). Such a type is called a raw type."


    Hmm.

    I agree that ArrayList[] is the type erasure of ArrayList<Node>[].
    However, I don't agree that ArrayList[] is "the erasure of a
    parameterized type" since ArrayList<Node>[] is not a parameterized type.
    §4.5 defines a parameterized type, and it doesn't include arrays whose
    component type is a parameterized type.

    --
    www.designacourse.com
    The Easiest Way To Train Anyone... Anywhere.

    Chris Smith - Lead Software Developer/Technical Trainer
    MindIQ Corporation
    Chris Smith, May 30, 2006
    #15
  16. jacksu

    Tony Morris Guest

    Re: JLS Interpretation (was Re: Java generic issue in array)

    > Exactly my point. The second edition has some complications (the worst I
    > can recall offhand being the rules for resolving method overloads), but
    > they can be mastered with a bit of study. This remains true for the 1.5
    > additions to the language other than generics.


    This particular rule changed three times since JDK 1.5.0 beta and once after
    JLS 3e draft was released.

    --
    Tony Morris
    http://tmorris.net/
    Tony Morris, May 30, 2006
    #16
  17. Re: JLS Interpretation (was Re: Java generic issue in array)

    "Tony Morris" <> wrote in message
    news:IR3fg.613$...
    >> Exactly my point. The second edition has some complications (the worst I
    >> can recall offhand being the rules for resolving method overloads), but
    >> they can be mastered with a bit of study. This remains true for the 1.5
    >> additions to the language other than generics.

    >
    > This particular rule changed three times since JDK 1.5.0 beta and once
    > after JLS 3e draft was released.


    Sorry, which rule was that? If it's resolving method overloads with the
    added complication of generics, I'm sure the result is horrific.

    Pre-generics overload resolution seems to have changed something during 1.4.
    It originally took the return type of an individual overload into account,
    but ceased to do so.
    Mike Schilling, May 30, 2006
    #17
  18. jacksu

    Dale King Guest

    Re: JLS Interpretation (was Re: Java generic issue in array)

    Chris Smith wrote:
    > <Dale King <"DaleWKing [at]gmail [dot] com">> wrote:
    >>> 4.8 (Raw Types) makes ArrayList[] NOT a raw type, even though its
    >>> component type is a raw type. Therefore we can't apply unchecked
    >>> conversion.

    >
    >> I think the problem is that last step where you say that ArrayList[] is
    >> not a raw type.
    >>
    >> 4.8 says:
    >>
    >> "To facilitate interfacing with non-generic legacy code, it is also
    >> possible to use as a type the erasure (§4.6) of a parameterized type
    >> (§4.5). Such a type is called a raw type."

    >
    > Hmm.
    >
    > I agree that ArrayList[] is the type erasure of ArrayList<Node>[].
    > However, I don't agree that ArrayList[] is "the erasure of a
    > parameterized type" since ArrayList<Node>[] is not a parameterized type.
    > §4.5 defines a parameterized type, and it doesn't include arrays whose
    > component type is a parameterized type.


    I certainly agree that section 4.5 still needs lots of work. It seems
    very much a work in progress which is apparent by all the discussion
    sections. But I think it is a stretch to say that ArrayList<Node>[] is
    not a parameterized type. It is quite obviously a parameterized type.

    I note that in 4.3 it says that an array is a reference type and
    "Reference types may be parameterized (§4.5) with type arguments (§4.4)".

    I went to see if this has been cleared up for 1.6, but the docs for 1.6
    point to the old pre-generic JLS.

    The 3rd edition of the JLS is supposedly not published yet and there is
    a feedback form on the website, so you might want to feed back that they
    need to be more precise.

    --
    Dale King
    Dale King, May 31, 2006
    #18
  19. jacksu

    Chris Smith Guest

    Re: JLS Interpretation (was Re: Java generic issue in array)

    Dale King wrote ...
    > I certainly agree that section 4.5 still needs lots of work. It seems
    > very much a work in progress which is apparent by all the discussion
    > sections. But I think it is a stretch to say that ArrayList<Node>[] is
    > not a parameterized type. It is quite obviously a parameterized type.


    It's certainly not "obviously" a parameterized type. Perhaps you're
    right that it's intended to be one, but on several readings I still
    can't find an interpretation that makes ArrayList<Node>[] fit that
    definition of a parameterized type. It's actually rather obvious to me
    that it is, in fact, NOT a parameterized type. You may disagree, but
    it's certainly not a stretch, and it's certainly far from obvious in the
    other direction.

    > I note that in 4.3 it says that an array is a reference type and
    > "Reference types may be parameterized (§4.5) with type arguments (§4.4)".


    That's interesting, to be sure. I'm not sure what to think of it. It's
    certainly written to imply that all three kinds of types may have
    arguments, and yet the snippets of grammar right below say very clearly
    otherwise.

    In the end, though, the type is not ArrayList[]<Node> (which would be
    illegal anyway), but rather ArrayList<Node>[]. In other words, it
    doesn't have type arguments. We could surmise that the JLS is using
    some kind of strange terminology that a type "has type arguments" if
    there are type arguments anywhere lexically inside the definition of the
    type, but that wouldn't be a very useful sort of terminology. Rather,
    it appears that the statement you quoted is true, but a stronger
    statement -- "All reference types may be parameterized with type
    arguments" -- is not true. In particular, array types never have type
    parameters.

    In either case, 4.5 is very specific: a parameterized type is a class or
    interface name, and then a list of type parameters. No arrays are
    possible, whether are not arrays are also considered to have type
    parameters.

    > The 3rd edition of the JLS is supposedly not published yet and there is
    > a feedback form on the website, so you might want to feed back that they
    > need to be more precise.


    I have a print copy of the JLS 3rd edition, so it is published at least
    under the common definition of that term. If it's still tentative,
    that's interesting. I haven't seen anything like that.

    --
    Chris Smith
    Chris Smith, May 31, 2006
    #19
  20. Re: JLS Interpretation (was Re: Java generic issue in array)

    "Chris Smith" <> wrote in message
    news:...
    >Dale King wrote ...



    >> The 3rd edition of the JLS is supposedly not published yet and there is
    >> a feedback form on the website, so you might want to feed back that they
    >> need to be more precise.


    > I have a print copy of the JLS 3rd edition, so it is published at least
    > under the common definition of that term. If it's still tentative,
    > that's interesting. I haven't seen anything like that.


    I have it as well. It's not labeled "rough draft" but it certainly reads
    like one..
    Mike Schilling, May 31, 2006
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Murat Tasan
    Replies:
    1
    Views:
    8,009
    Chaitanya
    Feb 3, 2009
  2. Replies:
    1
    Views:
    948
    Stefan Schulz
    Jan 2, 2006
  3. Replies:
    2
    Views:
    407
  4. fig000
    Replies:
    0
    Views:
    355
    fig000
    Nov 30, 2007
  5. minlearn
    Replies:
    2
    Views:
    436
    red floyd
    Mar 13, 2009
Loading...

Share This Page