On Tue, Jan 5, 2010 at 4:38 PM, Lex Spoon <sp...@google.com> wrote: > The main trick is in dealing with bridge methods. I believe they should be > ignored, because you can't normally call them in Java. However, we > unfortunately currently allow them. So, as a compromise, the latest patch > allows *direct* access to bridge methods, but it ignores them when resolving > a wildcard. >
To give an example, suppose StringHolder extends Settable<String>, like this: abstract class Settable<T> { abstract void set(T x); } class StringHolder { void set(String x) { /*...*/ } } >From the point of view of source code, StringHolder has only a single set() method, and it takes a String as an argument. However, in the Java bytecode, it will have two set methods: it will have the String one, and a bridge method that takes an Object as an argument. The Object one just forwards to the String one. The Object one would be used in code like this: void setToNull(Settable<T> settable) { settable.set(null); // calls the bridge method } The current patch considers @StringHolder::set(*) to be unambiguous, because it ignores bridge methods. Lex
-- http://groups.google.com/group/Google-Web-Toolkit-Contributors