3 ms·

The article makes multiple misleading claims. First, it calls unsound the fact that an exception gets thrown in the shown code. There is no data security issue

The article makes multiple misleading claims. First, it calls unsound the fact that an exception gets thrown in the shown code. There is no data security issue, no possible JVM escape, no type system failure. You can get the same cast exception with straight-forward code. The claim of unsoundness is merely based on the fact that the problem is obfuscated. Using unsound here is misleading. Second, the whole point relies on implicit type relations that are not checked at compile-time when nullptr is involved. Certainly, it's a weakness in the specification that can cause suprising run-time exceptions, but it's not a hole in the type system. Third, it makes claim that the JVM was saved by its early choice of backward compatibility. This is a bad habit that I've seen elsewhere: making claim about unspecified, unknown alternate histories. In this case, had generic not erased type, then assignment from nullptr would not work. Surely, the nullptr would have acquired typed alternative (nullptr<T>: nullptr<String>, nullptr<Integer> ...) which would have letthe compiler type-check properly and catch the problem at compile-time.

pchiusano 10y ago
It would be a security problem if you could cast any value to an int array without getting an exception (and without the resulting byte code containing any sort of check). And it sounds like there is no guarantee that the exception will be thrown? (Or maybe I misread) So that does seem very serious to me.
deleted 10y ago
[deleted]
scott_s 10y ago
Your first point runs counter to my understanding of what the author said. Specifically: "Here’s our “true” unsoundness example that has been making the rounds most recently. It assigns an Integer instance to a String variable. According to the Java specification, this program is well-typed, and according to the Java specification it should execute without exception (unlike the aforementioned backdoors) and actually assign the Integer instance to the String variable, violating the intended behavior of well-typed programs. Thus it illustrates that Java’s type system is unsound." That is, the author's unsoundness claim is independent of the class cast exception. On your second point, you may be in violent agreement with the author. What is the difference between "a weakness in the specification" and being "unsound"? The author's definition is that this is an unintentional hole in the type system, unlike the intentional ones he outlined.

pchiusano 10y ago

It would be a security problem if you could cast any value to an int array without getting an exception (and without the resulting byte code containing any sort of check). And it sounds like there is no guarantee that the exception will be thrown? (Or maybe I misread) So that does seem very serious to me.

deleted 10y ago

[deleted]

scott_s 10y ago

Your first point runs counter to my understanding of what the author said. Specifically: "Here’s our “true” unsoundness example that has been making the rounds most recently. It assigns an Integer instance to a String variable. According to the Java specification, this program is well-typed, and according to the Java specification it should execute without exception (unlike the aforementioned backdoors) and actually assign the Integer instance to the String variable, violating the intended behavior of well-typed programs. Thus it illustrates that Java’s type system is unsound." That is, the author's unsoundness claim is independent of the class cast exception. On your second point, you may be in violent agreement with the author. What is the difference between "a weakness in the specification" and being "unsound"? The author's definition is that this is an unintentional hole in the type system, unlike the intentional ones he outlined.