On Tue, Jan 5, 2010 at 4:38 PM, Lex Spoon <[email protected]> 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
