가변인수 메서드를 호출하면 가변인수를 담기 위한 배열이 자동으로 하나 만들어진다.
그런데 내부로 감춰야 했을 이 배열을 클라이언트에게 노출하는 문제가 생겼다.
그 결과 varargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 알기 어려운 컴파일 경고가 발생한다.
매개변수화 타입의 변수가 타입이 다른 객체를 참조하면 힙 오염이 발생한다.
이렇게 다른 타입 객체를 참조하는 상황에서 컴파일러가 자동 생성한 형변환이 실패할 수 있으니, 제네릭 타입 시스템이 약속한 타입 안전성의 근간이 흔들려 버린다.
static void dangerous(List<String>... stringLists) {
List<Integer> intList = List.of(42);
Object[] objects = stringLists;
objects[0] = intList; // Heap pollution
String s = stringLists[0].get(0); // ClassCastException
}
위의 메서드에서는 형변환하는 곳이 보이지 않는데도 인수를 건네 호출하면 ClassCastException을 던진다.
마지막 줄에 컴파일러가 생성한 (보이지 않는) 형변환이 숨어 있기 때문이다.
이처럼 타입 안전성이 깨지니 제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.
재미난 질문이 있다.
제네릭 배열을 프로그래머가 직접 생성하는 건 허용하지 않으면서 제네릭 varargs 매개변수를 받는 메서드를 선언할 수 있게 한 이유는 무엇일까?
그 답은 제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 메서드가 실무에서 매우 유용하기 때문이다.
자바 7 전에는 제네릭 가변인수 메서드의 작성자가 호출자 쪽에서 발생하는 경고에 대해서 해줄 수 있는 일이 없었다.
사용자는 이 경고들을 그냥 두거나 호출하는 곳마다 @SuppressWarnings("unchecked")
애너테이션을 달아 경고를 숨겨야 했다.
하지만 자바 7에서는 @SafeVarargs
애너테이션이 추가되어 제네릭 가변인수 메서드 작성자가 클라이언트 측에서 발생하는 경고를 숨길 수 있게 되었다.
@SafeVarargs
애너테이션은 메서드 작성자가 그 메서드 타입 안전함을 보장하는 장치다.
컴파일러는 이 약속을 믿고 그 메서드가 안전하지 않을 수 있다는 경고를 더 이상 하지 않는다.
그렇다면 어떻게 메서드가 안전한지 확신할 수 있을까?
가변인수 메서드를 호출할 때 varargs 매개변수를 담는 제네릭 배열이 만들어진다는 사실을 기억하자.
메서드가 이 배열에 아무것도 저장하지 않고 그 배열의 참조가 밖으로 노출되지 않는다면 타입 안전하다.
달리 말하면, 이 varargs 매개변수 배열이 호출자로부터 그 메서드로 순수하게 인수를 전달하는 일만 한다면 그 메서 드는 안전하다.
하지만 아래와 같은 코드는 varargs 매개변수 배열에 아무것도 저장하지 않고도 타입 안전성을 깰 수도 있다.
static <T> T[] toArray(T... args) {
return args;
}
이 메서드가 반환하는 배열의 타입은 이 메서드에 인수를 넘기는 컴파일 타임에 결정되는데, 그 시점에는 컴파일러에 충분한 정보가 주어지지 않아 타입을 잘못 판단할 수 있다.
따라서 자신의 varargs 매개변수 배열을 그대로 반환하면 힙 오염을 이 메서드 호출한 쪽의 콜스택으로 전이하는 결과를 낳을 수 있다.
제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면 안전하지 않다.
하지만 예외가 2가지 있다.
첫 번째, @SafeVarargs
로 제대로 애노테이트된 또 다른 varargs 메서드에 넘기는 것은 안전하다.
두 번째, 그저 이 배열 내용의 일부 함수를 호출하는 일반 메서드에 넘기는 것도 안전하다.
@SafeVarargs
애너테이션을 사용해야 할 때를 정하는 규칙은 간단하다.
제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 모든 메서드에 @SafeVarargs
를 다는 것이다.
그리고 아래 두 조건을 모두 만족하는 제네릭 varargs 메서드는 안전하다.
둘 중 하나라도 어겼으면 수정하여야 한다.