아이템 32 : 제네릭과 가변인수를 함께 쓸 때는 신중하라
가변인수는 메서드에 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 해주는데, 구현 방식에 허점이 있다. 가변인수 메서드를 호출하면 가변인수를 담기 위한 배열이 자동으로 하나 만들어진다. 그런데 내부로 감춰야 했을 이 배열을 그만 클라이언트에 노출하는 문제가 생겼다. 그 결과 varargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 알기 어려운 컴파일 경고가 발생한다.
실체화 불가 타입은 런타임에는 컴파일타임보다 타입 관련 정보를 적게 담고 있음을 배웠다. 그리고 거의 모든 제네릭과 매개변수화 타입은 실체화되지 않는다. 메서드를 선언할 때 실체화 불가 타입으로 varargs 매개변수를 선언하면 컴파일러가 경고를 보낸다. 가변인수 메서드를 호출할 때도 varargs 매개변수가 실체화 불가 타입으로 추론되면, 그 호출에 대해서도 경고를 낸다. 경고 형태는 대략 다음과 같다.
warning: [unchecked] Possible heap pollution from
parameterized vararg type List<String>
매개변수화 타입의 변수가 타입이 다른 객체를 참조하면 힙 오염이 발생한다.
아래 코드를 예제로 생각해보자.
1
2
3
4
5
6
|
static void dangerous(List<String>... stringLists) {
Object[] objects = stringLists;
objects[0] = intList; // 힙 오염 발생
String s = stringList[0].get(0) // ClassCastException
}
Colored by Color Scripter
|
이 메서드에서는 형변환하는 곳이 보이지 않는데도 인수를 건네 호출하면 ClassCastException을 던진다. 마지막 줄에 컴파일러가 생성한 (보이지 않는) 형변환이 숨어 있기 때문이다. 이처럼 타입 안전성이 깨지니 제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.
@SafeVarargs 애너테이션은 메서드 작성자가 그 메서드가 타입 안전함을 보장하는 장치다.
메서드가 안전한 게 확실하지 않다면 절대 @SafeVarargs 애너테이션을 달아서는 안 된다.
제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면 안전하지 않다.
@SafeVarargs 애너테이션을 사용해야 할 때를 정하는 규칙은 간단하다.
제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 모든 메서드에 @SafeVarargs를 달아야 한다. 그래야 사용자를 헷갈리게 하는 컴파일러 경고를 없앨 수 있다. 이 말은 안전하지 않은 varargs 메서드는 절대 작성해서는 안 된다는 뜻이기도 하다.
핵심 정리
가변인수와 제네릭은 궁합이 좋지 않다. 가변인수 기능은 배열을 노출하여 추상화가 완벽하지 못하고, 배열과 제네릭의 타입 규칙이 서로 다르기 때문이다. 제네릭 varargs 매개변수는 타입 안전하지는 않지만, 허용된다. 메서드에 제네릭 (혹은 매개변수화된) varargs 매개변수를 사용하고자 한다면, 먼저 그 메서드가 타입 안전한지 확인한 다음 @SafeVarargs 애너테이션을 달아 사용하는 데 불편함이 없게끔 하자.
'언어 > JAVA' 카테고리의 다른 글
[Effective Java] int 상수 대신 열거 타입을 사용하라 (0) | 2020.03.27 |
---|---|
[Effective Java] 타입 안전 이종 컨테이너를 고려하라 (0) | 2020.03.26 |
[Effective Java] 한정적 와일드카드를 사용해 API 유연성을 높이라 (0) | 2020.03.24 |
[Effective Java] 이왕이면 제네릭 메서드로 만들라 (0) | 2020.03.23 |
[Effective Java] 이왕이면 제네릭 타입으로 만들라 (0) | 2020.03.23 |