Java Auto-Synthesis

class Base<T> {
	T obj;
	Base(T obj) {
		this.obj = obj;
	}
	T getob() {
		return obj;
	}
}

class Sub extends Base<String> {
	Sub(String str) {
		super(str);
	}
	String getob() {
		return obj;
	}
}

How many methods of the sub-class in the above code snippet will have after compilation, and why? Let’s make it a little bit simpler: How many methods the sub-class will have, excluding the methods inherited from java.lang.Object?

The answer is simple: Just modify the subclass, add a main method with the code snippet below, and execute. It will print all the methods and, of course, do not consider the main method.

public class Sub extends Base<String> {
	Sub(String str) {
		super(str);
	}
	
  	@Override
  	String getob() {
		return obj;
  	}

  	public static void main(String args[]){
		for ( Method method : Sub.class.getDeclaredMethods()){
			System.out.println( “Method name:”+method.getName()+” | Return type :” +method.getReturnType());
		}
	}
}

Simple, right? But, wait: why am I seeing two methods for getob with two different return types “ java.lang.Object” and “java.lang.String”?

Method name: getob | Return type:class java.lang.Object
Method name: getob | Return type:class java.lang.String

We never defined a method getob() in our sub-class with a return type of java.lang.Object, which means  the compiler is creating it automatically...But why?

Well, let’s examine a little more before understating why. Modify the SOP statement to get some extra information about the methods.

public static void main(String args[]){
 for ( Method method : Sub.class.getDeclaredMethods() ){
 	System.out.println( "Method name"+method.getName()+" | Return type :" +method.getReturnType()+" | isBridge :"+method.isBridge());
 }
}

Method name: getob | Return type:class java.lang.Object | isBridge :true

Method name: getob | Return type:class java.lang.String | isBridge :false

Now as we print the method meta-data, we can see that the additional method which was created by the compiler is a “bridge” method, (isBridge= true). What is a bridge method and why does the compiler create it?

The bridge method is an interesting topic and often not required to be known by Java developers because those are created and maintained by the compiler.

Here I will discuss one of the aspects of the bridge method related to our above example. In Java 5 with the addition of Generic for type-safety compilers have something called type “erasure." This is a process where the compiler removes (erase) all information related to “type parameters” and “type arguments” within a class or method for the sake of being binary compatible with Java libraries/applications that were created before generics.

If that’s the case, things are supposed to break here, because if we pass any other kind of object as a Generic parameter (say, Integer), the compiler has erased the type information already. However, it actually doesn’t because that’s where "Bridges" in Generics comes into the picture.

When the compiler translates the code for binary compatibility with older applications, it also adds the required bridge methods automatically in order to sustain the implementation contracts.

Note the first line of the output: we haven’t defined anywhere the return type as java.lang.Object in either subclass or superclass, but the magic is done by the compiler and added a bridge method with a return type of java.lang.Object. If we pass Integer or any other type as a type parameter to the sub-class it will still work because of the bridge.

There are also other scenarios where bridge methods are generated by the compiler. One such case is method overriding and co-variant return type.