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

f.testTwo(f = newF, f)

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.

This is a rude response. The reason is quite reasonable, since there is no way that would work in all cases. A case is easily made where Foo<Number> extends Foo<Integer> makes as much sense as Foo<Integer> extends Foo<Number>.

So, which would you have chosen?

It didn't come across as rude to me. And i think it's entirely accurate.

Moreover, that pattern - of sending a variable with a wildcard type argument into a method with a type parameter so that the type argument gains a name - is a something i've seen and used many times, and is useful to know. I don't know if there is a name for this technique, but i call it "taming a wildcard".

In the example case, though, it isn't about giving it a name. It is about using the name in the first place. Is no different from:

    class Foo {
        void test(String arg) {..}
        main(..) {
          Foo foo = new Foo();
          Object s = "sd";
          foo.test(s); // Boom
        }
    }

Note that if that were instead:

    class Foo {
        void test(Number arg) {..}
        main(..) {
          Foo foo = new Foo();
          Long n = 4L;
          foo.test(n);
        }
    }

Then things work, because the subtyping is chosen. In the generics case, there is no relation between Foo<Number> and Foo<Integer>. If there were, then the capture could potentially treat Foo<?> as Foo<Object> and then depending on if you went co or contra, could allow the call.

I'm both sorry and baffled you found my response rude. As for your question, I'm afraid I don't understand it whatsoever. What am I supposed to be choosing? What does your case have to do with the comment I was replying to?