Actually, it's not in general decidable whether f.test(f) is safe because f gets read twice and the value might change in the meantime. In the example a simple flow analysis will tell you it doesn't but the general case is equivalent to the halting problem. The generic method solves the problem because now there is only one read in boom() and the concrete type in testFoo ensures that f can't change in an incompatible way between reads.
A more sophisticated type system could allow access if it can be proven safe with simple flow analysis but wildcards are already complicated, that would make them much more so for not much benefit.
> Actually, it's not in general decidable whether f.test(f) is safe because f gets read twice and the value might change in the meantime.
Might it? I can't see any way that actions in the current thread can change the value of f in between those two uses. Actions in another thread can be ignored until the receiving end of a happens-before relationship is encountered, and there isn't such a point inside that expression.
More generally, yes, two uses of the same wildcarded variable in one method might not yield objects with the same actual type argument. But in this case i think it's safe.
What I said didn't really make sense -- f.test(f) is a concrete example so how am I generalizing? What I meant was: in the general case of expressions that contain multiple references to the same variable it might, for instance
First, I wasn't speaking about a general case, I was speaking about the case presented.
Second, as of Java 8, the compiler knows whether a local variable is "effectively final". In the example given, f qualifies as effectively final. In earlier versions, my point stands that it's simply because the compiler isn't sophisticated enough.
The point I don't agree with is that it's really about the compiler. Had it been an optimization that doesn't affect which warnings or errors you get then yes, that's all the compiler. But what you need here is for the types of variables to incorporate flow analysis such that f gets compatible types on both reads if it doesn't change, and incompatible if it does. That would be an incredibly complex type system and people already struggle with how generics in java work.
A more sophisticated type system could allow access if it can be proven safe with simple flow analysis but wildcards are already complicated, that would make them much more so for not much benefit.