It is currently 21 Oct 2018, 02:20
   
Text Size

Generics & 'Type Erasure': disingenuous documentation?

Non-Application Specific Programming Stuff

Moderator: CCGHQ Admins

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

Postby cyberion » 08 Sep 2013, 20:10

Here is another example of what I am finding disingenuous:

Java interprets varargs as arrays.
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);
}
Method argument, "l", should first become List<String>[]

The line labelled "Valid" should actually give an unchecked warning.

Only at generation time should the <String> parameter be stripped, giving a List[].

But what unfortunately seems to be happening is that the compiler does it all in one hit and immediately translates the varargs parameter l to List[] in anticipation of type erasure. That is why there is no warning, not because the line is valid.

This is a glitch.

Why have they labeled it "valid" and then pretended to explain it?

If l were an explicit List<String>[], it would not anticipate type erasure. It would erase the type at the correct point and an unchecked error would be given!
cyberion
 
Posts: 15
Joined: 08 Sep 2013, 17:48
Has thanked: 0 time
Been thanked: 0 time

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

Postby fortion322 » 08 Sep 2013, 20:13

The line labelled valid will never give an unchecked warning, even if the parameter were a List<String>[].
Java Code:
private static void test(List<String>[] l) {
Object[] o = l; // This is valid
// do stuff
}
fortion322
 
Posts: 18
Joined: 05 Sep 2013, 12:58
Has thanked: 0 time
Been thanked: 0 time

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

Postby cyberion » 08 Sep 2013, 20:16

fortion322 wrote:The line labelled valid will never give an unchecked warning, even if the parameter were a List<String>[].
Java Code:
private static void test(List<String>[] l) {
Object[] o = l; // This is valid
// do stuff
}
You are right. It does not give an unchecked warning. Question is, shouldn't it?

I find this ambiguous..


So we have a "valid" statement which can potentially introduce heap pollution. What does "valid" mean then? Something is obviously skew-whiff.

I mean, am I supposed to believe that creating a List<String>[] is essentially invalid, or is it an artifact of the Java Language? Is it not odd that the assignment statement, which is the clear candidate for incompatibility issues, is being called the valid statement? I would say that validity is being controlled by circumstance rather than essence.
cyberion
 
Posts: 15
Joined: 08 Sep 2013, 17:48
Has thanked: 0 time
Been thanked: 0 time

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

Postby fortion322 » 08 Sep 2013, 20:16

No it shouldn't.
Casting an array of something to an Object[] is not something that needs checking since everything is rooted in the Object class.

It's possibly a side effect of the nature of arrays, but doesn't strike me as all that unusual.

It all, essentially, boils down to..."don't write bollocks code".
fortion322
 
Posts: 18
Joined: 05 Sep 2013, 12:58
Has thanked: 0 time
Been thanked: 0 time

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

Postby fortion322 » 08 Sep 2013, 20:18

No it shouldn't.
Casting an array of something to an Object[] is not something that needs checking since everything is rooted in the Object class.

It's possibly a side effect of the nature of arrays, but doesn't strike me as all that unusual.

It all, essentially, boils down to..."don't write bollocks code".
fortion322
 
Posts: 18
Joined: 05 Sep 2013, 12:58
Has thanked: 0 time
Been thanked: 0 time

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

Postby cyberion » 08 Sep 2013, 20:21

fortion322 wrote:No it shouldn't.
Casting an array of something to an Object[] is not something that needs checking since everything is rooted in the Object class.

It's possibly a side effect of the nature of arrays, but doesn't strike me as all that unusual.

It all, essentially, boils down to..."don't write bollocks code".
Well that is your opinion and I think it sidesteps the issue. The documentation says that it can lead to heap pollution and you are saying it doesn't need checking.

And as for what you think it boils down to, that is a cop out.

I wouldn't be surprised if what you are today defending, gets fixed. Then you'll be telling everyone how logical the new way is! :-)

I expect to see generic type information in the runtime in some future release. I don't really believe it is all that difficult. They just haven't got round to doing it. They can stamp an array with its type, so why not a List. They don't have to use the stamp to break backward compatibility, just to trap heap pollution at the point where it happens.
cyberion
 
Posts: 15
Joined: 08 Sep 2013, 17:48
Has thanked: 0 time
Been thanked: 0 time

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

Postby fortion322 » 08 Sep 2013, 20:23

But that would not fix the issue of casting SomeClass[] to an Object[], which has nothing at all to do with type erasure.
Which is the point I was replying to.

The above that you complained about being valid, is just as valid without touching Collections at all...
fortion322
 
Posts: 18
Joined: 05 Sep 2013, 12:58
Has thanked: 0 time
Been thanked: 0 time

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

Postby cyberion » 08 Sep 2013, 20:25

fortion322 wrote:But that would not fix the issue of casting SomeClass[] to an Object[], which has nothing at all to do with type erasure.
Which is the point I was replying to.

The above that you complained about being valid, is just as valid without touching Collections at all...
Yes it would. The documentation states that the assignment introduces possible heap pollution. If you classes are stamped with their type at runtime, their wouldn't be any heap pollution. It would throw a runtime exception.
cyberion
 
Posts: 15
Joined: 08 Sep 2013, 17:48
Has thanked: 0 time
Been thanked: 0 time

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

Postby fortion322 » 08 Sep 2013, 20:27

Which has nothing to do with type erasure, since that is something specific to generics, and:
Java Code:

Object[] objects = new SomeClass[]();


predates them by several years.

You are conflating two different things here.
Type erasure and everything extending Object.
The former may well get "fixed" (though I wouldn't hold my breath since you'll get a runtime exception as soon as you try and use an array that's been buggered up), the latter is not likely to.
fortion322
 
Posts: 18
Joined: 05 Sep 2013, 12:58
Has thanked: 0 time
Been thanked: 0 time

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

Postby fortion322 » 08 Sep 2013, 20:28

Which has nothing to do with type erasure, since that is something specific to generics, and:
Java Code:

Object[] objects = new SomeClass[]();


predates them by several years.

You are conflating two different things here.
Type erasure and everything extending Object.
The former may well get "fixed" (though I wouldn't hold my breath since you'll get a runtime exception as soon as you try and use an array that's been buggered up), the latter is not likely to.
fortion322
 
Posts: 18
Joined: 05 Sep 2013, 12:58
Has thanked: 0 time
Been thanked: 0 time

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

Postby cyberion » 08 Sep 2013, 20:32

fortion322 wrote:Which has nothing to do with type erasure, since that is something specific to generics, and:
Java Code:

Object[] objects = new SomeClass[]();


predates them by several years.

You are conflating two different things here.
Type erasure and everything extending Object.
The former may well get "fixed" (though I wouldn't hold my breath since you'll get a runtime exception as soon as you try and use an array that's been buggered up), the latter is not likely to.
Huh? Heap corruption has nothing to do with type erasure??? ***scratches head***

I am not conflating the issues. I am looking at them as a whole. You are looking at the assignment in isolation. Of course you can assign any reference type to object, and any array reference type to object array.

Put it this way, suppose I had a complex method which generated a warning about the conversion of its parameterized arguments. I didn't write the function, but I need to check where there may be possible misuse. The varargs themselves are not essentially the issue. That is just an artifact of how the Java compiler has been made to behave. The issue is at the assignment to object. That is where the vulnerability is exposed and where the compiler should flag. As it is, I could be left with some rather complex compilation analysis or be forced to relinquish the parametrization which may have been used in a totally proper way.
cyberion
 
Posts: 15
Joined: 08 Sep 2013, 17:48
Has thanked: 0 time
Been thanked: 0 time

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

Postby fortion322 » 08 Sep 2013, 20:36

We're obviously talking at cross-purposes.

The array assignment marked as Valid in the code snippet from the docs has always been valid, and is valid for things that do not involve generics. Therefore that assignment (which is the only thing I have been talking about here) is nothing to do with type erasure. It is simply down to the nature of extending from a base object (and the associated logic behind arrays).

So, as I said, it's a part of the language and is most unlikely to be changed.
fortion322
 
Posts: 18
Joined: 05 Sep 2013, 12:58
Has thanked: 0 time
Been thanked: 0 time

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

Postby cyberion » 08 Sep 2013, 20:39

I know it has been there since day 1. Object is at the top of the reference type hierarchy and can be assigned any reference type.

But, when you evolve a language, there is impact. You can't just say that what was valid in earlier versions remains totally valid. You are tweaking the semantic perspective on the language and there is regression. So, I find the argument that it is valid because it was valid before, to be wrong.

If you try to answer the question in my last post, you will see that the assignment to object ought now to be flagged, however valid it used to be before generics hit.

(Reminds me of the same thing in the world of science. You can't build a world perspective in way that is entirely incremental and without review. Perspectives break, just like Newtonian Dynamics)
cyberion
 
Posts: 15
Joined: 08 Sep 2013, 17:48
Has thanked: 0 time
Been thanked: 0 time

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

Postby fortion322 » 08 Sep 2013, 20:43

Why should the cast to Object[] be flagged though?
Will you flag casts to List<SomeClass>[] as well?
How about any cast?
Because that is essentially what you are suggesting...casting is always suspicious.
Which, to be frank, is nonsense.

Almost any artifact of a language is open to misuse.

I'm curious, in your work have you encountered a problem with this aspect of Java?
Because in over a decade working in it I honestly can't think of any in the stuff I've written or reviewed.

Same goes for type erasure as well, as a matter of fact.
Now, automatic primitive wrapping...that keeps causing trouble.
fortion322
 
Posts: 18
Joined: 05 Sep 2013, 12:58
Has thanked: 0 time
Been thanked: 0 time

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

Postby cyberion » 08 Sep 2013, 20:44

fortion322 wrote:Why should the cast to Object[] be flagged though?
Will you flag casts to List<SomeClass>[] as well?
How about any cast?
Because that is essentially what you are suggesting...casting is always suspicious.
Which, to be frank, is nonsense.

Almost any artifact of a language is open to misuse.

I'm curious, in your work have you encountered a problem with this aspect of Java?
Because in over a decade working in it I honestly can't think of any in the stuff I've written or reviewed.

Same goes for type erasure as well, as a matter of fact.
Now, automatic primitive wrapping...that keeps causing trouble.
No. The "nonsense" suggestion is entirely your own. Nowhere have I suggested flag all casts. If a cast fails at runtime, you know exactly where to look in the source code because it will tell you.

You are still avoiding addressing the scenario in my last but one post, which is why you think any old cast is equivalent.

The problem here is impact analysis. Earlier versions of Java didn't even flag the function declaration in the varargs problem. They only flagged the invocation. Now they've move the compiler error closer to the source of the error. But, as I said, please address the scenario, so that you comment more accurately on my perspective.
cyberion
 
Posts: 15
Joined: 08 Sep 2013, 17:48
Has thanked: 0 time
Been thanked: 0 time

PreviousNext

Return to General Programming

Who is online

Users browsing this forum: No registered users and 1 guest


Who is online

In total there is 1 user online :: 0 registered, 0 hidden and 1 guest (based on users active over the past 10 minutes)
Most users ever online was 279 on 11 Jul 2013, 22:03

Users browsing this forum: No registered users and 1 guest

Login Form