«

phi <> wrote:
> public class ListImplementation<T> implements generics.List<T> {
> Object [] data;

Just guessing... If you made this T[] typed, does the warning then
disappear? The array itself would not "know" the difference, but
the Compiler does.

> public T getFirst() {
> if (isEmpty()) {
> return null; }
> return (T) data[0]; } // <<---- WARNING

In that case, you then won't need the cast, either, but probably
it won't hurt.

Andreas Leitgeb wrote:
> phi <> wrote:
>> public class ListImplementation<T> implements generics.List<T> {
>> Object [] data;
>
> Just guessing... If you made this T[] typed, does the warning then
> disappear? The array itself would not "know" the difference, but
> the Compiler does.
>
>> public T getFirst() {
>> if (isEmpty()) {
>> return null; }
>> return (T) data[0]; } // <<---- WARNING
>
> In that case, you then won't need the cast, either, but probably
> it won't hurt.

I'd guess that just moves the warning, say to

T[] data = (T[])new Object[20];

Because

T[]data = new T[20];

is illegal.

Mike Schilling <> wrote:
>>> Object [] data;
>> Just guessing... If you made this T[] typed, ...
> I'd guess that just moves the warning, say to
> T[] data = (T[])new Object[20];
> Because
> T[]data = new T[20];
> is illegal.

Yes, I noticed after reading the other followup :-}

PS: I haven't tried "new T[...]", myself. I believe, that it
*could* theoretically work consistently, but thats moot, if
it isn't allowed in reality.

Andreas Leitgeb wrote:
> PS: I haven't tried "new T[...]", myself. *I believe, that it
> * *could* theoretically work consistently, but thats moot, if
> * it isn't allowed in reality.
>

Five minutes in the JLS uncovers:
"10.3 Array Creation
"... An array creation expression specifies the element type, ...
"It is a compile-time error if the element type is not a reifiable
type (§4.7)"

So, no, that expression is not allowed in reality.

--
Lew

Andreas Leitgeb wrote:
> Mike Schilling <> wrote:
>>>> Object [] data;
>>> Just guessing... If you made this T[] typed, ...
>> I'd guess that just moves the warning, say to
>> T[] data = (T[])new Object[20];
>> Because
>> T[]data = new T[20];
>> is illegal.
>
> Yes, I noticed after reading the other followup :-}
>
> PS: I haven't tried "new T[...]", myself. I believe, that it
> *could* theoretically work consistently, but thats moot, if
> it isn't allowed in reality.

It would cause problems, because the following would be legal code:

T[] arr = new T[20]; // Not legal now, but we're assuming
Object[] oarr = arr; // Legal in general, since we know that T
extends Object
arr[0] = new Object();// compile-time legal, and since the "real"
row type
// of the Array is Object, legal
at run time too
T t = arr[0]; // Uh-oh.

Mike Schilling <> wrote:
> Andreas Leitgeb wrote:
>> PS: I haven't tried "new T[...]", myself. I believe, that it
>> *could* theoretically work consistently, but thats moot, if
>> it isn't allowed in reality.

> It would cause problems, because the following would be legal code:
> T[] arr = new T[20]; // Not legal now, but we're assuming
> Object[] oarr = arr; // Legal in general, since we know that
> // T extends Object
> arr[0] = new Object(); // compile-time legal, and since the "real"
> // row type of the Array is Object, legal

You need of course "oarr[0]" for the assignment, but the argument
is then sound. I admit defeat of that former belief

> at run time too
> T t = arr[0]; // Uh-oh.

Andreas Leitgeb wrote:
> Mike Schilling <> wrote:
>> Andreas Leitgeb wrote:
>>> PS: I haven't tried "new T[...]", myself. I believe, that it
>>> *could* theoretically work consistently, but thats moot, if
>>> it isn't allowed in reality.
>
>> It would cause problems, because the following would be legal code:
>> T[] arr = new T[20]; // Not legal now, but we're assuming
>> Object[] oarr = arr; // Legal in general, since we know that
>> // T extends Object
>> arr[0] = new Object(); // compile-time legal, and since the
>> "real" // row type of the Array is
>> Object, legal
>
> You need of course "oarr[0]" for the assignment,

Right. It's difficult to test code that's based on a counterfactual
assumption

> but the argument
> is then sound. I admit defeat of that former belief
>
>> at run time too
>> T t = arr[0]; // Uh-oh.