varargs 매개변수를 사용하고자 한다면, 메서드의 type-safe를 확인하고 @SafeVarargs 어노테이션을 달아라
📌 가변인수 (varargs)
가변인수 메서드(Item 53)와 제네릭은 자바 5 때 함께 추가되었으나, 서로 잘 어우러지지는 못 했다.
가변인수는 메서드에 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 해준다.
public void print(String ... args){
for (String arg : args) {
System.out.println(arg);
}
}
그런데 내부로 감췄야 했을 이 배열을 클라이언트에 노출하는 문제가 생겼다.
그 결과 varargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 알기 어려운 컴파일 경고가 발생한다.
📌 가변인수와 제네릭 혼용의 문제점
Item 28에서 실체화 불가 타입은 런타임에는 컴파일 타임보다 타임 관련 정보를 적게 담고 있다고 배웠다.
거의 모든 제네릭과 매개변수화 타입이 실체화되지 않기 때문에, 자바는 제네릭 배열을 허용하지 않는다.
(배열은 런타임 시에 구성 요소 유형에 대한 정보를 포함하므로)
메서드를 선언할 때 실체화 불가 타입으로 varargs 매개변수 선언 시 컴파일러가 경고를 보낸다.
가변인수 메서드 호출할 때도 varargs 매개변수가 실체화 불가 타입으로 추론되면 경고를 보낸다.
✒️ 왜 금지가 아니라 경고만 보낼까?
제네릭 배열을 프로그래머가 직접 생성하는 건 컴파일 단계에서 막힌다.
그러나 제네릭 varargs 매개변수를 받는 메서드는 막지 않고 '경고'로 끝내는 이유가 모순처럼 느껴질 수 있다.
답은 제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 메서드가 실무에서 유용하기 때문이다.
언어 설계자는 이 모순을 수용하였고, 자바 라이브러리도 이런 메서드들(Array.asList(T... a), List.of(E... a)을 여럿 제공하고 있다.
하지만 이런 허용으로 인해 매개변수화 타입의 변수가 타입이 다른 객체를 참조하면 힙 오염이 발생한다.
다른 타입 객체를 참조하는 상황에서는 컴파일러가 자동 생성한 형변환이 실패할 수 있으니, 제네릭 타입 시스템이 약속한 타입 안전성의 근간이 흔들려버린다.
public class VarargsTest {
static void dangerous(List<String>... stringLists) {
List<Integer> ints = List.of(42);
Object[] objs = stringLists;
objs[0] = ints; // (1) 힙오염
String s = stringLists[0].get(0); // (2) runtime error - ClassCastException
}
@Test
void varargsErrTest() {
List<String> strings = new ArrayList<>();
strings.add("test");
dangerous(strings);
}
}
dangerous 메서드 마지막 줄에서 컴파일러가 생성한 (보이지 않는) 형변환에서 런타임 에러가 발생한다.
제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.
📌 @SafeVarargs
제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 모든 메서드에 @SafeVarargs를 달아라
그럼에도 사용하기로 결정했다면, 메서드 작성자가 type-safe을 보장하는 장치를 추가할 수 있다.
메서드가 안전한 게 확실치 않다면 절대 @SafeVarargs 어노테이션을 달아서는 안 된다.
메서드 안전성을 판단하는 근거는 아래 두가지이다.
- 메서드가 varargs 매개변수를 담는 배열에 아무것도 저장하지 않는 경우
- varargs 배열의 참조가 밖으로 노출되지 않는 경우
즉, varargs 매개변수 배열이 호출자로부터 순수하게 인수를 전달하는 일만 한다면, 그 메서드는 안전하다.
@SafeVarargs 어노테이션은 재정의할 수 없는 메서드에만 달아야 한다.
정적 메서드, final 인스턴스 메서드, private 인스턴스 메서드(Java8부터)에 붙일 수 있다.
📌 Bad Case. 배열의 참조를 노출하는 경우
static <T> T[] toArray(T... args) {
return args;
}
해당 메서드가 반환하는 배열 타입은 컴파일 시점에 결정된다.
그 시점에서는 컴파일러에게 충분한 정보가 주어지지 않아 타입을 잘못 판단할 수 있다.
따라서 자신의 varargs 매개변수 배열을 그대로 반환하면, 호출자 쪽의 콜스택까지 힙 오염을 전이하게 될 수도 있다.
static <T> T[] toArray(T... args) { // String[] 배열이 만들어진다.
return args;
}
public static void main(String[] args) {
String[] strings = toArray("좋은", "빠른", "저렴한");
}
위 예시는 컴파일 시점에 T를 String 타입으로 추론이 가능해서 문제가 없다.
public class VarargsTest {
static <T> T[] toArray(T... args) { // warning : Possible heap pollution from parameterized vararg type
return args;
}
static <T> T[] pickTwo(T a, T b, T c) {
switch (ThreadLocalRandom.current().nextInt(3)) {
case 0: // warning : Unchecked generics array creation for varargs parameter
return toArray(a, b);
case 1: // warning : Unchecked generics array creation for varargs parameter
return toArray(a, c);
case 2: // warning : Unchecked generics array creation for varargs parameter
return toArray(b, c);
}
throw new AssertionError();
}
@Test
void heapPollutionTest() {
String[] attrs = pickTwo("좋은", "빠른", "저렴한");
}
}
그러나 위 코드는 문제가 발생한다. 해당 스니펫은 타입 추론이 2번 발생하기 때문이다.
- pickTwo(T a, T b, T c)에서 T 타입은 인자로 넘긴 String 타입을 보고 타입 추론이 가능하다.
- toArray(a, b)로 넘어갈 때 Object 타입으로 넘어가므로, toArray(T... args)의 args 타입은 Object[] 타입이 된다.
결과적으로 Object[] 타입을 호출자에게 넘겨주게 되고, String[] 타입으로 캐스팅하다가 ClassCastExeption이 발생한다.
제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면 안전하지 않다.
단, 예외가 2가지 있다.
1️⃣ @SafeVarargs로 제대로 어노테이션된 또 다른 varargs 메서드에 넘기는 것은 안전하다.
2️⃣ 이 배열 내용의 일부 함수를 호출만 하는 (varags를 받지 않는) 일반 메서드에 넘기는 것도 안전하다.
📌 Good Case. flatten 메서드
@SafeVarargs
static <T> List<T> flatten(List<? extends T>... lists) {
List<T> result = new ArrayList<>();
for (List<? extends T> list : lists)
result.addAll(list);
return result;
}
flatten 메서드는 임의 개수 리스트를 인수로 받아, 받은 순서대로 모든 원소를 하나의 리스트로 옮겨 담아 반환한다.
위의 가변인수는 lists의 인자를 전달만 하고 있으므로 type-safe하다.
static <T> List<T> flatten(List<List<? extends T>> lists) {
List<T> result = new ArrayList<>();
for (List<? extends T> list : lists)
result.addAll(list);
return result;
}
Item 28의 조언에 따라 (실체는 배열인) varargs 매개변수를 List 매개변수로 바꿀 수도 있다.
varargs는 배열에 대한 암시적 배열 생성에 불과하기 때문이다.
audience = flatten(List.of(friends, romans, countrymen));
정적 팩터리 메서드 List.of를 활용하여, 이 메서드에 임의의 개수의 인수를 넘기는 것이 가능해진다.
그 이유는 List.of에도 @SafeVarargs 어노테이션이 달려 있기 때문이다.
이 방식은 컴파일러가 type-safe를 검증할 수 있으며, 어노테이션을 우리가 직접 달지 않아도 된다.
클라이언트 코드가 살짝 지저분해지고 속도가 느려질 수 있다는 단점이 있기는 하다.
pickTwo에도 똑같은 방식으로 적용할 수 있다.
static <T> List<T> pickTwo(T a, T b, T c) {
System.out.println(a.getClass().getName());
switch (ThreadLocalRandom.current().nextInt(3)) {
case 0:
return List.of(a, b);
case 1:
return List.of(b, c);
case 2:
return List.of(a, c);
}
throw new AssertionError();
}
public static void main(String[] args) {
List<String> strings = pickTwo("좋은", "빠른", "저렴한");
}
결과 코드는 배열 없이 제네릭만 사용하므로 타입 안전하다.