Java generic issue in array

[Dale King]

Dale King wrote ...
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.

I did some more reading and think perhaps it is not a question of
whether it is parameterized, but whether it is reifiable. And I must say
that the reifiable discussion is very fuzzy to me. They have a section
in chapter 4 on it, but the word is not even used in chapter 5.

The question is whether you consider ArrayList[] to be a raw type. 4.8
says a raw type is "The name of a generic type declaration used without
any accompanying actual type parameters." I think that would be
applicable. This gives us a path through section 5.2 (identity
conversion followed by unchecked conversion because it is a raw type).

At the end of chapter 10 on arrays in the section on the runtime
ArrayStoreException it has a discussion section that says:

"If the element type of an array were not reifiable (§4.7), the virtual
machine could not perform the store check described in the preceding
paragraph. This is why creation of arrays of non-reifiable types is
forbidden. One may declare variables of array types whose element type
is not reifiable, but any attempt to assign them a value will give rise
to an unchecked warning (§5.1.9)."

According to 4.7 ArrayList<Node>[] is not reifiable and so any attempt
to assign to it should give the unchecked warning. It would be nice if
this information were incorporated into section 5.1.9.

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'm just going by what the website said. I see now that it is just out
of date information since it says "the physical book should be available
in June 2005."

It would still be a good idea to provide feedback that they might add
some errata or clarification.

 

[Chris Smith]

I did some more reading and think perhaps it is not a question of
whether it is parameterized, but whether it is reifiable. And I must say
that the reifiable discussion is very fuzzy to me. They have a section
in chapter 4 on it, but the word is not even used in chapter 5.

The question is whether you consider ArrayList[] to be a raw type. 4.8
says a raw type is "The name of a generic type declaration used without
any accompanying actual type parameters." I think that would be
applicable. This gives us a path through section 5.2 (identity
conversion followed by unchecked conversion because it is a raw type).

Yes, it would. I was using the earlier definition from the previous
sentence ("type erasure of a parameterized type"). The spec claims that
this second definition is more precise; I disagree, since I don't see
any clear definition of what constitutes a generic type declaration.
However, for the sake of discussion and because implementations seem to
support it, we'll adopt your view that ArrayList[] is the name of a
generic type declaration. Still, unchecked conversion (5.1.9) presents
a problem, since the target of unchecked conversion is a parameterized
type, and I previously explained why I don't think that

At the end of chapter 10 on arrays in the section on the runtime
ArrayStoreException it has a discussion section that says:

"If the element type of an array were not reifiable (§4.7), the virtual
machine could not perform the store check described in the preceding
paragraph. This is why creation of arrays of non-reifiable types is
forbidden. One may declare variables of array types whose element type
is not reifiable, but any attempt to assign them a value will give rise
to an unchecked warning (§5.1.9)."

Yes, so this seems to say that 5.1.9 ought to apply to conversion of
array types. I believe this is an internal contradiction within the
language specification. There is no way to reconcile the above
statement with the definition of unchecked conversion in 5.9 and the
definition of a parameterized type in 4.5. Although the section you
quote is non-normative, it still indicates a problem in that the actual
consequences of the language spec conflict not only with existing
implementations, but also with the clearly stated intent of the
specification itself.

It would still be a good idea to provide feedback that they might add
some errata or clarification.

Yes, I agree.

 

[Dale King]

I did some more reading and think perhaps it is not a question of
whether it is parameterized, but whether it is reifiable. And I must say
that the reifiable discussion is very fuzzy to me. They have a section
in chapter 4 on it, but the word is not even used in chapter 5.

The question is whether you consider ArrayList[] to be a raw type. 4.8
says a raw type is "The name of a generic type declaration used without
any accompanying actual type parameters." I think that would be
applicable. This gives us a path through section 5.2 (identity
conversion followed by unchecked conversion because it is a raw type).

Yes, it would. I was using the earlier definition from the previous
sentence ("type erasure of a parameterized type"). The spec claims that
this second definition is more precise; I disagree, since I don't see
any clear definition of what constitutes a generic type declaration.
However, for the sake of discussion and because implementations seem to
support it, we'll adopt your view that ArrayList[] is the name of a
generic type declaration. Still, unchecked conversion (5.1.9) presents
a problem, since the target of unchecked conversion is a parameterized
type, and I previously explained why I don't think that

At the end of chapter 10 on arrays in the section on the runtime
ArrayStoreException it has a discussion section that says:

"If the element type of an array were not reifiable (§4.7), the virtual
machine could not perform the store check described in the preceding
paragraph. This is why creation of arrays of non-reifiable types is
forbidden. One may declare variables of array types whose element type
is not reifiable, but any attempt to assign them a value will give rise
to an unchecked warning (§5.1.9)."

Yes, so this seems to say that 5.1.9 ought to apply to conversion of
array types. I believe this is an internal contradiction within the
language specification. There is no way to reconcile the above
statement with the definition of unchecked conversion in 5.9 and the
definition of a parameterized type in 4.5. Although the section you
quote is non-normative, it still indicates a problem in that the actual
consequences of the language spec conflict not only with existing
implementations, but also with the clearly stated intent of the
specification itself.

Then I think we are in agreement. It is clear from the JLS that the
assignment should be allowed, but the JLS is not being precise enough
for a language lawyer and could definitely be cleaned up and made more
explicit.

 

[Chris Smith]

Then I think we are in agreement. It is clear from the JLS that the
assignment should be allowed, but the JLS is not being precise enough
for a language lawyer and could definitely be cleaned up and made more
explicit.

Yes, in a way. I'd add the caveat that the only thing that convinces me
that allowing the assignment is intended to be legal is the non-
normative "Discussion" section at the end of chapter 10... that and the
behavior of the current implementation. I think I'd use the word "fix"
rather than "clean up."

 

[Mike Schilling]

Yes, in a way. I'd add the caveat that the only thing that convinces me
that allowing the assignment is intended to be legal is the non-
normative "Discussion" section at the end of chapter 10... that and the
behavior of the current implementation.

And that, naively, you'd expect it be allowed (or I would, anyway.) There's
a lot to be said for Least Astonishment.