[아이템 32] 제네릭과 가변인수를 함께 쓸 때는 신중하라

[Why]

가변인수는 메서드에 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 해주는데, 구현 방식에 허점이 있다.

• 가변인수 메서드를 호출하면 가변인수를 담기 위한 배열이 자동으로 하나 만들어진다.
• 그런데 내부로 감춰야 했을 이 배열을 그만 클라이언트에 노출하는 문제가 생겼다.
• 그 결과 varargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 알기 어려운 컴파일 경고가 발생한다.

static void dangerous(List<String>... stringLists) {
    List<Integer> intList = List.of(42);
    Object[] objects = stringLists;
    objects[0] = intList;             // 힙 오염 발생
    String s = stringLists[0].get(0); // ClassCastException

이 메서드에서는 형변환하는 곳이 보이지 않는데도 ClassCastException을 던진다.

• 마지막 줄에 컴파일러가 생성한 보이지 않는 형변환이 숨어있기 때문이다.
• 이처럼 타입 안전성이 깨지니 제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.

그런데 제네릭 배열은 오류를 내면서 위의 제네릭 가변인수는 경고만을 던진다.

• 실체화 불가 타입(제네릭, 매개변수화 타입)의 varargs 매개변수를 받는 메서드가 실무에서 매우 유용하기 때문이다.

 

[When]

제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면 안전하지 않다!

예외는 다음 두 가지다.

• @SafeVarags로 제대로 애노테이트된 또다른 varargs 메서드에 넘기는 것은 안전하다.
• 그저 이 배열 내용의 일부 함수를 호출만 하는 (varargs를 받지 않는) 일반 메서드에 넘기는 것도 안전하다.

 

[How]

결론

1. 다음 두 조건을 만족하는 제네릭 varargs 메서드는 안전하다.

• varargs 매개변수 배열에 아무것도 저장하지 않는다.
• 그 배열(혹은 복제본)을 신뢰할 수 없는 코드에 노출하지 않는다.

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

2. 이왕이면 아이템28의 조언을 따라 실체는 배열인 varargs 매개변수를 List 매개변수로 바꾸자.

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

 

제네릭 가변인수를 사용한다면...

자바 7에서는 @SafeVarargs 애너테이션이 추가되어 제네릭 가변인수 메서드 작성자가 클라이언트 측에서 발생하는 경고를 숨길 수 있게 되었다.

• @SafeVarargs 애너테이션은 메서드 작성자가 그 메서드가 타입 안전함을 보장하는 장치다.
• 메서드가 안전한 게 확실하지 않다면 절대 @SafeVarargs 애너테이션을 달아서는 안 된다.
• @SafeVarargs 애너테이션은 재정의할 수 없는 메서드에만 달아야 한다.

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

varargs 매개변수 배열에 아무것도 저장하지 않고도 타입 안전성을 깰 수도 있으니 주의해야 한다.

• 위 메서드가 반환하는 배열의 타입은 이 메서드에 인수를 넘기는 컴파일타임에 결정되는데, 그 시점에는 컴파일러에게 충분한 정보가 주어지지 않아 타입을 잘못 판단할 수 있다.
• 따라서 자신의 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에 넘길 T 인스턴스 2개를 담을 varargs 매개변수 배열을 만드는 코드를 생성한다.
• 배열의 타입은 Object[]인데, pickTwo에 어떤 타입의 객체를 넘기더라도 담을 수 있는 가장 구체적인 타입이기 때문이다.
• 그리고 toArray 메서드가 돌려준 이 배열이 그대로 pickTwo를 호출한 클라이언트까지 전달된다.

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

위 코드는 클라이언트이다.

• 실행하면 ClassCastException을 던진다.
• pickTwo의 반환값을 attributes에 저장하기 위해 String[]로 형변환하는 코드를 컴파일러가 자동 생성한다는 점을 놓쳤다.
• Object[]는 String[]의 하위 타입이 아니므로 이 형변환은 실패한다.
• 제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하면 안전하지 않다.