Comments on Nirav's Contemplations: Scala v/s Java arrays

A[] a1 = new A[1]; B[] b1 = new B[1]; b1 = a1; //T...

2009-05-14T19:02:00.000-04:00

A[] a1 = new A[1];
B[] b1 = new B[1];
b1 = a1; //Type mismatch

In this example you cannot cast the A[] to a B[] because A is not a B. The other way works fine though.

a1 = b1;

..., but then it blows up when inserting a simple A ...

a1[0] = new A();

You can also force the A[] to B[] cast. This will of course blow up.

b1 =

If it is not truly a generics issue, can you enlig...

2009-05-14T10:17:00.000-04:00

If it is not truly a generics issue, can you enlighten me why the example code in post compiles without error and why following code does't?

A[] a1 = new A[1];
B[] b1 = new B[1];
b1 = a1; //Type mismatch

Because that's the only issue I have problem with.

I agree with previous posters. This has nothing to...

2009-05-14T03:57:00.000-04:00

I agree with previous posters. This has nothing to do with generics, merely a legacy of java arrays, which are with us since 1995. (Don't you think it's kind of old news in mid-2009?)

Also, arrays of course have types, distinct from their component types. (Here is even how these types are represented in bytecode, for example [I is int[], [[D a double[][] etc).

If this was

Think I wasn't precise enough, I am not disagreein...

2009-05-13T19:45:00.000-04:00

Think I wasn't precise enough, I am not disagreeing about generics in Java for types isn't a problem, it is generics and array as the post title says which attracts confusion.

I don't get any benefit out of generifying the array (by that I mean, a method signature with generic array types in it).

You can't "generify" an array. If you specify a ge...

2009-05-13T18:08:00.000-04:00

You can't "generify" an array.
If you specify a generic variable/parameter, it's normal that you can put subclasses to it.

new ArrayList<A>().add(new B());
new ArrayList<A[]>().add(new B[1]);

There's no difference in here, no breaking of the generics: B[] is a subclass of A[], because B is a subclass of A.

Hardcoded, thoredge: This is indeed generics issu...

2009-05-13T12:22:00.000-04:00

Hardcoded, thoredge:

This is indeed generics issue, IMO.
The raw arrays in Java are covariant by default. Which is fine, but when I generify them I expect it to be non-variant. Just like List <String> is not List<Object> without view bounds, arrays should also not be co-variant unless of course I add bounds and wildcards. Why should I use generics if I wanted to have

Have to agree with Hardcoded here. This has nothin...

2009-05-13T12:03:00.000-04:00

Have to agree with Hardcoded here. This has nothing to do without generics. A simpler example of this problem can be expressed this way:

public class UnGenerics {
static class A {
}
static class B extends A {
}
public static void main(String[] args) {
insert(new A(), new B[1]);
}
private static void insert(A a,

The problem you're describing has nothing todo wit...

2009-05-13T11:18:00.000-04:00

The problem you're describing has nothing todo with Generics, but with the array hierarchy.

The JLS defines that B[] is a subclass of A[]. This causes a lot of confusion and you're right with your critic about it.

But this is contrary to generic types, which are, per default, invariant:

static List<T> merge(List<T> l1, List<T> l2, List<

Java arrays are covariant because James Gosling (a...

2009-05-13T11:17:00.000-04:00

Java arrays are covariant because James Gosling (and friends) thought it was a good idea at the time. The problem is that Java 1 *didn't* have generics, so the only way to provide utility methods like System.arraycopy was to make arrays covariant in their value type. It was actually worse back in Java 1: there were *no* runtime checks for array storage problems. Thus, your code would probably