클래스와 인터페이스 선언에 타입 매개변수(type parameter)가 쓰이면, 이를 제네릭 클래스 혹은 제네릭 인터페이스라 한다. List 인터페이스는 원소의 타입을 나타내는 타입 매개변수 E를 받는다. 그래서 이 인터페이스의 완전한 이름은 List<E> 지만, 짧게 그냥 List라고도 자주 쓰인다. 제네릭 클래스와 제네릭 인터페이스를 통틀어 제네릭 타입(generic type)이라 한다.
각각의 제네릭 타입은 일련의 매개변수화 타입(parameterized type)을 정의한다. 먼저 클래스 이름이 나오고, 이어서 꺾쇠괄호 안에 실제 타입 매개변수들을 나열한다.
마지막으로, 제네릭 타입을 하나 정의하면 그에 딸린 로 타입(raw type)도 함께 정의된다. 로 타입이란 제네릭 타입에서 타입 매개변수를 전혀 사용하지 않을 때를 말한다. 로 타입은 타입 선언에서 제네릭 타입 정보가 전부 지워진 것처럼 동작하는데, 제네릭이 도래하기 전 코드와 호환되도록 하기 위한 억지로 짜낸 방법이라 할 수 있다.
제네릭을 지원하기 전에는 컬렉션을 다음과 같이 선언했다. 자바 9에서도 여전히 동작하지만 좋은 예라고 볼 수는 없다.
//Stamp 인스턴스만 취급한다.
private final Collection stamps = ...;
이 코드를 사용하면 실수로 도장(Stamp) 대신 동전(Coin)을 넣어도 아무 오류없이 컴파일되고 실행된다(컴파일러가 모호한 경고 메시지를 보여주긴 할 것이다).
// 실수로 동전을 넣는다.
stamps.add(new Coin(...)); // "unchecked call" 경고를 내린다.
컬렉션에서 이 동전을 다시 꺼내기 전에는 오류를 알아채지 못한다.
for (Iterator i = stamps.iterator(); i.hasNext(); ) {
Stamp stamp = (Stamp) i.next(); // ClassCastException을 던진다.
stamp.cancel();
}
이 책 전반에서 이야기하듯, 오류는 가능한 한 발생 즉시, 이상적으로는 컴파일할 때 발견하는 것이 좋다. 이 오류는 런타임에야 알아챌 수 있는데, 이렇게 되면 런타임에 문제를 겪는 코드와 원인을 제공한 코드가 물리적으로 상당히 떨어져 있을 가능성이 커진다. ClassCastException이 발생하면 stamps에 동전을 넣은 지점을 찾기 위해 코드 전체를 훑어봐야 할 수도 있다. 주석은 컴파일러가 이해하지 못하니 별 도움이 되지 못한다. 제네릭을 활용하면 이 정보가 주석이 아닌 타입 선언 자체에 녹아든다.
private final Collection<Stamp> stamps = ...;
이렇게 선언하면 컴파일러는 stamps에는 Stamp의 인스턴스만 넣어야 함을 컴파일러가 인지하게 된다. 따라서 아무런 경고 없이 컴파일된다면 의도대로 동작할 것임을 보장한다. 물론 컴파일러 경고를 숨기지 않았어야 한다. 이제 stamps에 엉뚱한 타입의 인스턴스를 넣으려 하면 컴파일 오류가 발생하며 무엇이 잘못됐는지를 정확히 알려준다.
Test.java9: error: incompatible type: Coin cannot be converted
to Stamp
stamps.add(new Coin());
⌃
컴파일러는 컬렉션에서 원소를 꺼내는 모든 곳에 보이지 않는 형변환을 추가하여 절대 실패하지 않음을 보장한다. Stamp용 컬렉션에 Coin을 넣는다는 예가 억지스러워 보이겠지만, 현업에서도 종종 일어나는 일이다. 앞에서도 얘기했듯, 로 타입을 쓰는 걸 언어 차원에서 막아 놓지는 않았지만 절대로 써서는 안 된다. 로 타입을 쓰면 제네릭이 안겨주는 안전성과 표현력을 모두 잃게된다. 그렇다면 절대 써서는 안 되는 로 타입을 애초에 왜 만들어놓은 걸까? 바로 호환성 때문이다. 자바가 제네릭을 받아들이기까지 거의 10년이 걸린 탓에 제네릭 없이 짠 코드가 이미 세상을 뒤덮어 버렸다. 그래서 기존 코드를 모두 수용하면서 제네릭을 사용하는 새로운 코드와도 맞물려 돌아가게 해야만 했다. 로 타입을 사용하는 메서드에 매개변수화 타입의 인스턴스를 넘겨도 동작해야만 했던 것이다. 이 마이그레이션 호환성을 위해 로 타입을 지원하고 제네릭 구현에는 소거 방식을 사용하기도 했다.
List 같은 로 타입은 상요해서는 안 되나, List<Object>처럼 임의 객체를 허용하는 매개변수화 타입은 괜찮다. 로 타입인 List와 매개변수화 타입인 List<Object>의 차이는 무엇일까? 간단히 이야기하자면, List는 제네릭 타입에서 완전히 발을 뺀 것이고, List<Object>는 모든 타입을 허용한다는 의사를 컴파일러에 명확히 전달한 것이다. 매개변수로 List를 받는 메서드에 List<String>을 넘길 수 있지만, List<Object>를 받는 메서드에는 넘길 수 없다. 이는 제네릭의 하위 타입 규칙 때문이다. 즉, List<String>은 로 타입인 List의 하위 타입이지만, List<Object>의 하위 타입은 아니다. 그 결과, List<Object> 같은 매개변수화 타입을 사용할 때와 달리 List 같은 로 타입을 사용하면 타입 안전성을 잃게 된다.
제네릭 타입을 쓰고 싶지만 실제 타입 매개변수가 무엇인지 신경쓰고 싶지 않다면 비한정적 와일드카드 타입(unbounded wildcard type)인 물음표('?')를 대신 사용하는게 좋다. 예컨대 제네릭 타입인 Set<E>의 비한정적 와일드카드 타입은 Set<?>다. 이것이 어떤 타입이라도 담을 수 있는 가장 범용적인 매개변수화 Set 타입이다.
static int numElementsInCommon(Set<?> s1, Set<?> s2) { ... }
비한정적 와일드카드 타입인 Set<?>와 로 타입인 Set의 차이는 무엇일까? 특징을 간단히 말하자면 와일드카드 타입은 안전하고, 로 타입은 안전하지 않다. 로 타입 컬렉션에는 아무 원소나 넣을 수 있으니 타입 불변식을 훼손하기 쉽다. 반면 Collection<?> 에는 (null 외에는) 어떤 원소도 넣을 수 없다. 다른 원소를 넣으려 하면 컴파일할 때 다음의 오류 메시지를 보게 될 것이다.
WildCard.java:13: error: incompatible types: String cannot be
converted to CAP#1
c.add("verboten");
⌃
where CAP#1 is a fresh type-variable:
CAP#1 extends Object from capture of ?
보충설명이 필요한 메시지긴 하지만, 어쨋든 컴파일러는 제 역할을 한 것이다. 즉, 컬렉션의 타입 불변식을 훼손하지 못하게 막았다. 구체적으로는, (null 외의) 어떤 원소도 Collection<?>에 넣지 못하게 했으며 컬렉션에서 꺼낼 수 있는 객체의 타입도 전혀 알 수 없게 했다. 이러한 제약을 받아들일 수 없다면 제네릭 메서드나 한정적 와일드카드 타입을 사용하면 된다.
로 타입을 쓰지 말라는 규칙에도 몇몇 예외가 있다. class 리터럴에는 로 타입을 써야 한다. 자바 명세는 class 리터럴에 매개변수화 타입을 사용하지 못하게 했다. 예를 들어 List.class, String[].class, int.class는 허용하고 List<String>.class와 List<?>.class는 허용하지 않는다. 두 번째 예외는 instanceof 연산자와 관련이 있다. 런타임에는 제네릭 타입정보가 지워지므로 instanceof 연산자는 비한정적 와일드카드 타입 이외의 매개변수화 타입에는 적용할 수 없다. 그리고 로 타입이든 비한정적 와일드카드 타입이든 instanceof는 완전히 똑같이 동작한다. 비한정적 와일드카드 타입의 꺾쇠괄호와 물음표는 아무런 역할 없이 코드만 지저분하게 만드므로, 차라리 로 타입을 쓰는 편이 깔끔하다. 다음은 제네릭 타입에 instanceof를 사용하는 올바른 예다.
if (o instanceof Set) { // 로 타입
Set<?> s = (Set<?>) o; // 와일드카드 타입
...
}
o의 타입이 Set임을 확인한 다음 와일드카드 타입인 Set<?>로 형변환해야 한다. 이는 검사 형변환(checked cast)이므로 컴파일러 경고가 뜨지 않는다.
