원문링크

용어 메서드 시그니처(method signature): 메서들간에 개성 주는것으로 자바 컴파일러인지 메서드 시그니처를 기준으로 오버로딩을 한다. 자바에서는 메서드명, 파라미터 갯수, 파라미터 타입, 파라미터 순서(자바에서는 리턴타입은 시그니처가 아니다.) - 파라미터명도 시그니처인지는 아리까리하다. 메서드 오버로딩를 생각하면 맞는거 같은데… 좀더 생각해보고 내용 수정 예정 콘크리트 타입, 구현타입(concrete type): 자바에서는 타입들중 interface, abstract class를 제외하고 남은 class를 concrete 타입으로 이해하면 될 듯.참고링크 - 영문: 번역 예정

제네릭스, 상속, 서브타입 Generics, Inheritance, and Subtypes

타입간 호환이된다면 특정 타입의 객체를 다른 타입에 할당이 가능합니다. 아래의 코드처럼 Object 타입은 Integer의 슈퍼타입중 하나이기 때문에 Integer 타입인 someInteger의 객체가 Object 타입인 someObject에 할당이 가능합니다.
As you already know, it is possible to assign an object of one type to an object of another type provided that the types are compatible. For example, you can assign an Integer to an Object, since Object is one of Integer’s supertypes:

Object someObject = new Object();
Integer someInteger = new Integer(10);
someObject = someInteger;   // OK

객체지향 이론에서는 이를 “is a”(~는 ~이다) 관계라고 부른다. Integer는 Object의 “is a”이므로 Integer 타입을 Object 타입에 할당이 가능하다. 하지만 Integer는 Number 타입에 “is a” 관계이다. 그러므로 아래의 코드는 잘 동작한다.
In object-oriented terminology, this is called an “is a” relationship. Since an Integer is a kind of Object, the assignment is allowed. But Integer is also a kind of Number, so the following code is valid as well:

public void someMethod(Number n) { /* ... */ }

someMethod(new Integer(10));   // OK
someMethod(new Double(10.1));   // OK

위의 룰은 generics도 마찬가지다. generic 타입을 호출할때, 타입인자가 Number 타입과 호환되는 “is a” 관계라면 Number 타입으로 타입인자를 전달한다.
The same is also true with generics. You can perform a generic type invocation, passing Number as its type argument, and any subsequent invocation of add will be allowed if the argument is compatible with Number:

Box<Number> box = new Box<Number>();
box.add(new Integer(10));   // OK
box.add(new Double(10.1));  // OK

아래의 메서드를 살펴보자
Now consider the following method:

public void boxTest(Box<Number> n) { /* ... */ }

어떤 타입을 인자로 받을수 있을까? 메서드의 시그니처를 보면, Box 타입의 객체 하나를 인자로 받는 메서드이다. 그럼, Box<Integer>나 Box<Double>을 인자로 넣을수 있을까? 아니다! 왜냐하면 Box<Integer>, Box<Double>는 Box<Number>의 서브타입이 아니기 때문이다. (자바에서는 꺽쇠안에 Number 타입은 컴파일러가 is a관계를 파악하지 못한다. - 공변성, 반공변성쪽 내용 참조하면 좋은데 자바는 이를 지원 못함. 스칼라 언어 참조. 눈이 공부하다보면 팽팽 돔.)
What type of argument does it accept? By looking at its signature, you can see that it accepts a single argument whose type is Box. But what does that mean? Are you allowed to pass in Box or Box, as you might expect? The answer is “no”, because Box and Box are not subtypes of Box.

이것은 generics를 공부할때 흔히 겪는 문제이다. 하지만 generic을 공부할때 중요한 컨셉이다.
This is a common misunderstanding when it comes to programming with generics, but it is an important concept to learn.

Box<Integer> is not a subtype of Box<Number> even though Integer is a subtype of Number.
Number의 서브타입인 Integer를 가진 Box<Integer>는 Box<Number>의 서브타입이 아니다.
Box is not a subtype of Box even though Integer is a subtype of Number.

중요: A와 B 두 구현타입을 제공할때(예를 들어 Number와 Integer),A와 B가 “is a” 관계가 있든 상관없이 MyClass<A>는 MyClass<B>와 더 이상 관계가 형성되지 않는다.
Note: Given two concrete types A and B (for example, Number and Integer), MyClass has no relationship to MyClass, regardless of whether or not A and B are related. The common parent of MyClass and MyClass is Object.

두 generic 클래스들간에 서브타입처럼 타입매개변수가 관련있다라는 정보를 주려면(컴파일러에게), 와일드카드와 서브타이핑 항목을 보라
For information on how to create a subtype-like relationship between two generic classes when the type parameters are related, see Wildcards and Subtyping.

제네릭 클래스와 서브타이핑 Generic Classes and Subtyping

generic 클래스 상속 또는 generic 인터페이스 만들 때, 만드는 타입을 상속(또는 구현) 받은 부모 generic 타입의 서브 generic 타입(자식타입)으로 두 타입간에 관계(is a)를 만들수 있다.
You can subtype a generic class or interface by extending or implementing it. The relationship between the type parameters of one class or interface and the type parameters of another are determined by the extends and implements clauses.

Collections 클래스들 사용할 때 예를 들면, ArrayList<E>는 List<E>를 구현했고 List<E>는 Collection을 상속했다. 그러므로 ArrayList<String>은 List<String>의 서브타입이고 List<String>은 Collection<String>의 서브타입니다. 그럼 <String>이라는 형식인자를 변경하지 않으면 타입간 서브타이핑 관계가 유지된다.
Using the Collections classes as an example, ArrayList implements List, and List extends Collection. So ArrayList is a subtype of List, which is a subtype of Collection. So long as you do not vary the type argument, the subtyping relationship is preserved between the types.

A sample Collections hierarchy
콜렉션들간의 계층구조 예
sample Collections hierarchy

PayloadList라는 인터페이스를 정의할 때 P라는 generic 타입을 메서드의 파라메터로 사용한다고했을때, 아래 코드와 같을 것이다.
Now imagine we want to define our own list interface, PayloadList, that associates an optional value of generic type P with each element. Its declaration might look like:

interface PayloadList<E,P> extends List<E> {
  void setPayload(int index, P val);
  ...
}

List<String>의 서브타입이면서 PayloadList가 타입인자로 전달할수 있는 것은 아래처럼 다양하게 볼수 있다.(일부임.)
The following parameterizations of PayloadList are subtypes of List:

  • PayloadList
  • PayloadList
  • PayloadList

A sample PayloadList hierarchy