Java Generic Interface vs Generic Methods, and whe

Question

I was wondering, aside from syntactic difference, when would one use a generic interface over a method that accepts a generic parameter?

public interface Flight<T>{
   void fly(T obj);
}

over

public interface Flight{
    void <T> fly(T obj);
}

Answer 1

You should use a generic type when you expect that most of the methods, in the implementations, will perform operations on the type supplied when instantiating the class.

For example, ArrayList<E> is a generic type since most of its operations (add, get, remove etc.) rely on the type specified upon creation of one.

A generic method should be used when only a few methods in the class rely upon the different types.

You can read more about generics in the Java Docs.

Answer 2

If you declare a generic method, you always let the caller decide, which type arguments to use for the type parameters. The implementation of the method must be able to deal with all possible types arguments (and it doesn’t even have a way to ask for the actual type arguments).

That said, a method like <T> void fly(T obj); states that the caller may use any type for T while the only thing the implementation can rely on is that the actual type for T will be assignable to Object (like if <T extends Object> had been declared).

So in this specific example, it’s not different to the declaration void fly(Object obj);, which also allows arbitrary objects.

In contrast, a type parameter on an interface is part of the contract and may be specified or restricted by an implementation of the interface:

public interface Flight<T>{
   void fly(T obj);
}

allows implementations like

public class X implements Flight<String> {
   public void fly(String obj) {
   }
}

fixing the type of T on the implementation side. Or

public class NumberFlight<N extends Number> implements Flight<N> {
   public void fly(N obj) {
   }
}

being still generic but restricting the type.

---

The signature of an interface is also important when the interface itself is a part of another method signature, e.g.

public void foo(Flight<? super String> f) {
    f.fly("some string value");
}

here, the Flight implementation, which you pass to foo, must be capable of consuming a String value, so Flight<String> or Flight<CharSequence> or Flight<Object> are sufficient, but not Flight<Integer>. Declaring such a contract requires type parameters on the interface, not at the interface’s methods.

Answer 3

Take for example the class java.util.ArrayList<E>. When creating variables of that type, you have to specify a concrete type for T:

ArrayList<String> list = new ArrayList<>();

These concrete types are used, when calling methods from the List interface, that work with the type T. Calling the add method, you can only add String objects to the list. Retrieving elements from the list using get, you will get elements of the concrete type String.

For generic methods, the type T is specified only for this method. And it would make more sense if the methods returns a value of that generic type. You often find code like this:

MyObject obj = SomeClass.staticGenericMethod(MyObject.class)

or

MyObject obj = classInstance.genericMethod(MyObject.class);

And you should start your interface name with a capital letter: Flight<T>