4 ms·

There isn't really a good reason. The compiler just isn't sophisticated enough to support it. You could always write a generic method to do it for you: s

by peeters 12y ago

There isn't really a good reason. The compiler just isn't sophisticated enough to support it. You could always write a generic method to do it for you: static <T> void testFoo(Foo<T> f) { f.test(f); } static void boom() { Foo<?> f = new Foo<String>(); testFoo(f); // works just fine } So the problem isn't that what you're doing is fundamentally unsafe, it's just that Java has no syntax to capture `?` except through a generic type parameter on a method or class.

taeric 12y ago
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?
- twic 12y ago
  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".
  - taeric 12y ago
    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.
    - deleted 12y ago
      [deleted]
- peeters 12y ago
  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?
plesner 12y ago
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.
- twic 12y ago
  > 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.
  - plesner 12y ago
    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)
- peeters 12y ago
  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.
  - 12y ago

by peeters 12y ago

taeric 12y ago

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?

twic 12y ago
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".
- taeric 12y ago
  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.
  - deleted 12y ago
    [deleted]
peeters 12y ago
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?

plesner 12y ago

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.

twic 12y ago
> 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.
- plesner 12y ago
  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)
peeters 12y ago
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.
- 12y ago