[이펙티브 자바] item 32 - 제네릭과 가변인수를 함께 쓸 때는 신중하라

■가변인수란?

가변인수는 메서드에 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 해주는 기법이다.

static void test(List<String>... param) { }

가변인수 메서드는 제네릭과 함께 자바5에 추가되었다.

아쉽게도 이 둘은 서로 잘 어우러지지 않는다.

■가변인수의 허점

가변인수는 구현 방식에 허점이 있다.

가변인수 메서드를 호출하면 가변인수를 담기 위한 배열이 자동으로 하나 만들어진다.

그런데 내부로 감춰야 했을 이 배열이 클라이언트에 노출된다는 단점이 있다.

그 결과 varargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 

알기 어려운 컴파일 경고가 발생한다.

---

거의 모든 제네릭과 매개변수화 타입은 실체화되지 않는다.

(item 28에서 실체화 불가 타입은 런타임에는 

컴파일타임보다 타입 관련 정보를 적게 담고 있음을 배웠다.)

메서드를 선언할 때 실체화 불가 타입으로 varargs 매개변수를 선언하면 

컴파일러가 경고를 보낸다.

가변인수 메서드를 호출할 때도 varargs 매개변수가 실체화 불가 타입으로 추론되면

그 호출에 대해서도 아래와 같은 경고를 낸다.

매개변수화 타입의 변수가 타입이 다른 객체를 참조하면 힙 오염이 발생한다.

다른 타입의 객체를 참조하는 상황에서는 컴파일러가 자동 생성한 형변환이 

실패할 수 있으니 제네릭 타입 시스템이 약속한 타입 안정성의 근간이 흔들려버린다.

다음 예제를 살펴보자

static void dangerous(List<String>... stringLists) {
    Object[] objects = stringLists;
    objects[0] = Arrays.asList(1, 2);
    String s = stringLists[0].get(0);
}

이 메서드에서는 형변환하는 곳이 보이지 않는다.

그러나 실제로 실행해보면 ClassCastException을 던진다.

왜냐하면 마지막 줄에 컴파일러가 생성한 형변환이 숨어있기 때문이다.

이처럼 타입 안정선이 쉽게 깨질 수 있기 때문에 

제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.

■그럼에도 불구하고 제네릭 varargs 매개변수를 허용하는 이유?

제네릭 배열을 프로그래머가 직접 생성하는건 허용하지 않으면서

제네릭 varargs 매개변수를 받는 메서드를 선언할 수 있게 한 이유는 무엇일까?

List<String>[] stringLists = new List<String>[10]; //선언 불가

왜냐하면 제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 매서드가

실무에서 매우 유용하기 때문이다! 그래서 언어 설계자는 이 모순을 수용하기로 했다.

자바 라이브러리도 이런 메서드를 여럿 제공한다.

- Arrays.asList(T... a)

- Collections.addAll(Collection<? super T> c, T... elements)

- EnumSet.of(E first, E... rest)

이 메서드들은 타입 안전하게 설계되어 있다.

(어떤 것이 타입 안전한지는 아래에서 설명될 것이다.)

■@SafeVarargs

자바 7 전에는 (안전한) 제네릭 가변인수 메서드의 작성자가 

호출자 쪽에서 발생하는 경고에 대해서 해줄 수 있는 일이 없었다.

따라서 이런 메서드는 사용하기에 좀 꺼림칙했다.

사용자는 이 경고들을 그냥 두거나 호출하는 곳마다

@SuppressWarnings("unchecked") 애너테이션을 달아

경고를 숨겨야 했다. (item 27)

이는 지루한 작업이고, 가독성을 떨어뜨리며, 때로는 진짜 문제를

알려주는 경고마저 숨기는 안 좋은 결과로 이어졌다.

---

자바 7에서는 @SafeVarargs 애너테이션이 추가되었다.

@SafeVarargs 애너테이션은 메서드 작성자가 그 메서드가 타입 안전함을 보장하는 장치다.

덕분에 제네릭 가변인수 메서드 작성자가 클라이언트 측에서 발생하는

경고를 숨길 수 있게 되었다.

컴파일러는 @SafeVarargs의 안전함을 믿고 그 메서드에 대해 더이상 경고하지 않는다.

■안전한 메서드에만 @SafeVarargs를 달자

메서드가 확실히 안전하지 않다면 절대 @SafeVarargs 애너테이션을 달면 안된다.

그렇다면 메서드가 안전한지는 어떻게 확신할 수 있을까?

가변인수 메서드를 호출할 때 

varargs 매개변수를 담는 제네릭 배열이 만들어진다는 사실을 기억하자.

메서드가 이 배열에 아무것도 저장하지 않고(그 매개변수들을 덮어쓰지 않고)

그 배열의 참조가 밖으로 노출되지 않으면(신뢰할 수 없는 코드가 

배열에 접근할 수 없다면) 타입 안전하다고 할 수 있다.

달리 말하면, 이 varargs 매개변수 배열이 호출자로부터 그 메서드로 순수하게 인수들을 

전달하는 일만 한다면 (varargs의 목적대로만 쓰인다면) 그 메서드는 안전하다.

---

다음은 varargs 매개변수 배열에 아무것도 저장하지 않지만 

배열의 참조가 밖으로 노출될 가능성이 있어 타입 안전하지 않은 코드이다.

static <T> T[] toArray(T... args) {
    return args;
}

이 코드는 가변인수로 넘어온 매개변수들을 배열에 담아 반환하는 제네릭 메서드다.

얼핏 보면 편리한 유틸리티로 보이지만, 보기와 달리 위험하다!

이 메서드가 반환하는 배열의 타입은 이 메서드에 인수를 넘기는 컴파일타임에 결정된다.

그 시점에는 컴파일러에게 충분한 정보가 주어지지 않아 

타입을 잘못 판단할 수 있다.

따라서 자신의 varargs 매개변수 배열을 그대로 반환하면 

힙 오염을 이 메서드를 호출한 쪽의 콜스택으로까지 전이하는 결과를 낳을 수 있다.

 

구체적인 예를 통해 위 위험을 살펴보자.

static <T> T[] pickTwo(T a, T b, T c) {
    switch (ThreadLocalRandom.current().nextInt(3)) {
        case 0:
            return toArray(a, b);
        case 1:
            return toArray(a, c);
        case 2:
            return toArray(b, c);
    }
    throw new AssertionError();// 도달할 수 없다.
} 

이 메서드는 제네릭 가변인수를 받는 toArray 메서드를 호출한다는 점만 빼면

위험하지 않고 경고도 내지 않는다.

이 메서드를 본 컴파일러는 toArray에 넘길 T 인스턴스 2개를 담을 

varargs 매개변수 배열을 만드는 코드를 생성한다.

이 코드가 만드는 배열의 타입은 Object[]이다. 

pickTwo에 어떤 타입의 객체를 넘기더라도 담을 수 있는 

가장 구체적인 타입이기 때문이다.

그리고 toArray 메서드가 돌려준 이 Object[] 배열이 

그대로 pickTwo를 호출한 클라이언트까지 전달된다.

즉, pickTwo는 항상 Object[] 타입 배열을 반환한다.

다음은 pickTwo를 호출하는 코드이다.

public static void main(String[] args) {
    String[] attributes = pickTwo("좋은", "빠른", "저렴한");
}

아무런 문제가 없는 메서드이니 별다른 경고 없이 컴파일된다.

하지만 실행하려 들면 형변환하는 곳이 보이지 않아도 ClassCastException을 던진다. 

왜냐하면 pickTwo의 반환값을 attributes에 저장하기 위해 

String[]로 변환하는 코드가 컴파일러에 의해 자동 생성되기 때문이다.

Object[]는 String[]의 하위 타입이 아니므로 이 형변환은 실패한다.

이 실패가 다소 황당하게 느껴질 수 있다.

왜냐하면 힙 오염을 발생시킨 진짜 원인인 toArray로부터 두 단계나 떨어져 있고

varargs 매개변수 배열은 실제 매개변수가 저장된 후 변경된 적도 없기 때문이다.

---

이 예는 제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면

안전하지 않다는 점을 다시 한번 상기시킨다. 단, 예외가 두 가지 있다.

첫 번째, @SafeVarargs가 선언된 또 다른 varargs 메서드에 넘긴는 것은 안전하다.

두 번째, 해당 배열 내용의 일부 함수를 호출만 하는(varargs를 받지 않는)

일반 메서드에 넘기는 것도 안전하다.

아래 코드는 제네릭 varargs 매개변수를 안전하게 사용하는 전형적인 예다.

@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 메서드는 임의 개수의 리스트를 인수로 받고

받은 순서대로 그 안의 모든 원소를 하나의 리스트로 옮겨 반환한다.

이 메서드에는 @SafeVarargs 애너테이션이 달려 있으니

선언하는 쪽과 사용하는 쪽 모두에서 경고를 내지 않는다.

---

@SafeVarargs 애너테이션을 사용해야 할 때를 정하는 규칙은 간단하다.

제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 모든 메서드에

@SafeVarargs를 달자. 그래야 사용자를 헷갈리게 하는 컴파일러 경고를 없앨 수 있다.

이 말은 안전하지 않은 varargs 메서드는 

절대 작성하지 말야야 한다는 뜻이기도 하다.

자신이 컨트롤할 수 있는 메서드 중 제네릭 varargs 매개변수를 사용하며

힙 오염 경고가 뜨는 메서드가 있다면, 그 메서드가 진짜 안전한지 점검하자.

정리하자면, 다음 두 조건을 모두 만족하는 제네릭 varargs 메서드는 안전하다.

- varargs 매개변수 배열에 아무것도 저장하지 않는다.

- 그 배열(혹은 복제본)을 신뢰할 수 없는 코드에 노출하지 않는다.

@SafeVarargs 애너테이션은 재정의할 수 없는 메서드에만 달아야 한다.

재정의한 메서드도 안전할지는 보장할 수 없기 때문이다.

자바 8에서 이 애너테이션은 오직 정적 메서드와 final 인스턴스 메서드에만

붙일 수 있고, 자바 9부터는 private 인스턴스 메서드에도 허용된다.

■@SafeVarargs 대신 List 사용하기

@SafeVarargs 애너테이션이 유일한 정답은 아니다.

item 28의 조언을 따라 (실체는 배열인) varargs 매개변수를 List 매개변수로 바꿀 수도 있다.

이 방식을 앞서의 flatten 메서드에 적용하면 다음처럼 된다.

매개변수 선언만 수정했음에 주목하자.

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;
}

정적 팩터리  메서드인 List.of를 활용하면 

다음 코드와 같이 이 메서드에 임의 개수의 인수를 넘길 수 있다.

이렇게 사용하는 게 가능한 이유는 List.of에 @SafeVarargs 애너테이션이 있기 때문이다.

List<Integer> flatList = flatten(List.of(List.of(1, 2), List.of(3, 4, 5), List.of(6,7)));

이 방식의 장점은 컴파일러가 이 메서드의 타입 안전성을 검증할 수 있다는 데 있다.

@SafeVarargs 애너테이션을 우리가 직접 달지 않아도 되며

실수로 안전하다고 판단할 걱정도 없다.

단점이라면 클라이언트 코드가 살짝 지저분해지고 속도가 조금 느려질 수 있다는 정도다.

---

또한 이 방식은 varargs 메서드를 안전하게 작성하는 게 불가능한 상황에서도 쓸 수 있다.

static <T> List<T> pickTwo(T a, T b, T c) {
    switch(ThreadLocalRandom.current().nextInt(3)) {
        case 0: return List.of(a, b);
        case 1: return List.of(a, c);
        case 2: return List.of(b, c);
    }
    throw new AssertionError();
}

기존 toArray의 List 버전이 바로 List.of로, 자바 라이브러리 차원에서 제공하니 

우리가 직접 작성할 필요도 없다.

그리고 메인 메서드는 다음처럼 쓸 수 있다.

public static void main(String[] args) {
    List<String> attributes = pickTwo("좋은", "빠른", "저렴한");
    System.out.println(attributes);
}

결과 코드는 배열 없이 제네릭만 사용하므로 타입 안전하다.