As you can see, the bridge method has been included. (The comment was added by the author,
and not by javap.)
There is one last point to make about bridge methods. Notice that the only difference
between the two getob( ) methods is their return type. Normally, this would cause an error,
but because this does not occur in your source code, it does not cause a problem and is handled
correctly by the JVM.
Ambiguity Errors
The inclusion of generics gives rise to a new type of error that you must guard against:
ambiguity. Ambiguity errors occur when erasure causes two seemingly distinct generic
declarations to resolve to the same erased type, causing a conflict. Here is an example that
involves method overloading:
// Ambiguity caused by erasure on
// overloaded methods.
class MyGenClass<T, V> {
T ob1;
V ob2;
// ...
// These two overloaded methods are ambiguous
// and will not compile.
void set(T o) {
ob1 = o;
}
void set(V o) {
ob2 = o;
}
}
Notice that MyGenClass declares two generic types: T and V. Inside MyGenClass, an
attempt is made to overload set( ) based on parameters of type T and V. This looks reasonable
because T and V appear to be different types. However, there are two ambiguity problems here.
First, as MyGenClass is written, there is no requirement that T and V actually be different
types. For example, it is perfectly correct (in principle) to construct a MyGenClass object as
shown here:
MyGenClass<String, String> obj = new MyGenClass<String, String>()
In this case, both T and V will be replaced by String. This makes both versions of set( )
identical, which is, of course, an error.
The second and more fundamental problem is that the type erasure of set( ) reduces both
versions to the following:
void set(Object o) { // ...
Thus, the overloading of set( ) as attempted in MyGenClass is inherently ambiguous.
Search WWH :
