Thread: Generics & 'Type Erasure': disingenuous documentation?

Show us an example then...as code.

I presume you have encountered something that does cause a problem in real life, and not merely as a mental exercise, that you could use here to illustrate your concerns.

Then explain how you would restructure the byte code and JVM to handle this case (note, the array problem not the generics one) that does not cause backward compatibility problems. And maybe then you might see that this is rather unlikely to be tackled anytime soon.

Originally Posted by fortioni

Show us an example then...as code.

I presume you have encountered something that does cause a problem in real life, and not merely as a mental exercise, that you could use here to illustrate your concerns.

Then explain how you would restructure the byte code and JVM to handle this case (note, the array problem not the generics one) that does not cause backward compatibility problems. And maybe then you might see that this is rather unlikely to be tackled anytime soon.

I think you are still looking at things in isolation and trying to separate one issue from the other, when they are joined at the hip.

We have already seen a SIMPLE example of the problem from the Java Trail...

Java Code:

public static void faultyMethod(List<String>... l) {
// Valid
Object[] objectArray = l;
objectArray[0] = Arrays.asList(new Integer(42));
// ClassCastException thrown here
String s = l[0].get(0);
}

If this happened in real life, I would need to get at the line labeled "valid", because that assignment is the most specific one that relates to the incompatibility, and is amenable to the compiler. From there I can check what objectArray is doing that is violating l or any of its potentially many aliases.

In a far more complex scenario, there may be many such candidates aliasing l in complex ways. The compiler should flag them.

If I get a runtime exception, because the exception doesn't happen at the point of heap pollution, all I get to know is that something corrupted l. And the compiler only flags whole methods and says, "it's in one of these, chief".

So I would have to examine the whole of the code: the method referenced by the runtime exception and methods in its call graph that were flagged, instead of specific variables. The "don't code crap argument doesn't really stand". In practice, you are often faced with debugging complex code you did not write yourself.

But as I said, that example is bollocks code.
If I saw that in some real code I would take it out back and have it shot.

How should the compiler know that the above is not a valid cast?
And what changes are required in the runtime to make a runtime exception occur at the point of assignment? Presumably every "array[i] = something" will have to have a check the "something" is allowed in the underlying object?

This is still a mental exercise. Do you have a concrete example?

If you don't then maybe you might realise why this is not likely to be dealt with.