가변인수(varargs) 메소드와 제네릭은 서로 잘 어우러지리라 기대하겠지만, 슬프게도 그렇지 않다. 가변인수는 메소드에 넘기는 인수의 개수를 클라이언트가 조절할 수 있게 해주는데, 구현 방식에 허점이 있다. 가변인수 메소드를 호출하면 가변인수를 담기 위한 배열이 자동으로 하나 만들어지는데, 내부로 감춰야 했을 이 배열을 그만 클라이언트에 노출하는 문제가 생겼다. 그 결과 varargs 매개변수에 제네릭이나 매개변수화 타입을 포함되면 알기 어려운 컴파일 경고가 발생한다.
메소드를 선언할 때 실체화 불가 타입으로 varargs 매개변수를 선언하면 컴파일러가 경고를 보낸다. 가변인수 메소드를 호출할 때도 varargs 매개변수가 실체화 불가 타입으로 추론되면, 그 호출에 대해서도 경고를 낸다. 매개변수화 타입의 변수가 타입이 다른 객체를 참조하면 힙 오염이 발생한다. 이렇게 다른 타입 객체를 참조하는 상황에서는 컴파일러가 자동 생성한 형변환이 실패할 수 있으니, 제네릭 타입 시스템이 약속한 타입 안전성의 근간이 흔들려버린다.
1 2 3 4 5 6 7 | // 제네릭과 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 } | cs |
이 메소드의 마지막 줄에 컴파일러가 생성한 보이지 않는 형변환이 숨어 있기 때문에, ClassCastException을 던진다. 이처럼 타입 안전성이 깨지니 제네릭 varargs 배열 매개변수에 값을 저장하는 것은 안전하지 않다.
제네릭 배열을 프로그래머가 직접 생성하는 건 허용하지 않으면서 제네릭 varargs 매개변수를 받는 메소드를 선언할 수 있게 한 이유는 실무에서 매우 유용하기 때문이다. 이런 메소드의 예로는 Arrays.asList(T... a), Collections.addAll(Collection<? super T> c, T... elements), EnumSet.of(E first, E... rest)가 대표적이다. 다행인 점은 이들은 타입 안전하다.
자바 7에서는 @SafeVarargs 애너테이션이 추가되어 제네릭 가변인수 메소드 작성자가 클라이언트 측에서 발생하는 경고를 숨길 수 있게 되었다. @SafeVarargs 애너테이션은 메소드 작성자가 그 메소드가 타입 안전함을 보장하는 장치다. 메소드가 안전한 게 확실하지 않다면 절대 @SafeVarargs 애너테이션을 달아서는 안 된다.
가변인수 메소드를 호출할 때 varargs 매개변수를 담는 제네릭 배열이 만들어지는데, 이 배열에 아무것도 저장하지 않고(그 매개변수들을 덮어쓰지 않고) 그 배열의 참조가 밖으로 노출되지 않는다면(신뢰할 수 없는 코드가 배열에 접근할 수 없다면) 타입 안전하다. 달리 말하면, 이 varargs 매개변수 배열이 호출자로부터 그 메소드로 순수하게 인수들을 전달하는 일만 한다면(varargs)의 목적대로만 쓰인다면) 그 메소드는 안전하다. 이 때, varargs 매개변수 배열에 아무것도 저장하지 않고도 타입 안전성을 깰 수도 있으니 주의해야 한다.
1 2 3 4 | // 자신의 제네릭 매개변수 배열의 참조를 노출한다. - 안전하지 않다! static <T> T[] toArray(T... args) { return args; } | cs |
이 메소드가 반환하는 배열의 타입은 이 메소드에 인수를 넘기는 컴파일타임에 결정되는데, 그 시점에는 컴파일러에게 충분한 정보가 주어지지 않아 타입을 잘못 판단할 수 있다. 따라서 자신의 varargs 매개변수 배열을 그대로 반환하면 힙 오염을 이 메소드를 호출한 쪽의 콜스택으로까지 전이하는 결과를 낳을 수 있다. 이 예는 제네릭 varargs 매개변수 배열에 다른 메소드가 접근하도록 허용하면 안전하지 않다는 점을 다시 한번 상기시킨다. 단 두가지 예외가 있는데, 첫 번째, @SafeVarargs로 제대로 애노테이트된 또 다른 varargs 메소드에 넘기는 것은 안전하다. 두 번째, 그저 이 배열 내용의 일부 함수를 호출만 하는(varargs를 받지 않는) 일반 메소드에 넘기는 것도 안전하다.
1 2 3 4 5 6 7 8 | // 제네릭 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; } | cs |
@SafeVarargs 애너테이션을 사용해야 할 때를 정하는 규칙은 간단하다. 제네릭이나 매개변수화 타입의 varargs 매개변수를 받는 모든 메소드에 @SafeVarargs를 달라. 그래야 사용자를 헷갈리게 하는 컴파일러 경고를 없앨 수 있다. 이 말은 안전하지 않은 varargs 메소드는 절대 작성해서는 안 된다는 뜻이기도 하다. 정리하자면 varargs 매개변수 배열에 아무것도 저장하지 않고, 그 배열(혹은 복제본)을 신뢰할 수 없는 코드에 노출하지 않으면 제네릭 varargs 메소드는 안전하다.
단, @SafeVarargs 애너테이션은 재정의할 수 없는 메소드에만 달아야 한다. 재정의한 메소드도 안전할지는 보장할 수 없기 때문이다. 자바 8에서 이 애너테이션은 오직 정직 메소드와 final 인스턴스 메소드에만 붙일 수 있고, 자바 9부터는 private 인스턴스 메소드에도 허용된다.
@SafeVarargs 애너테이션이 유일한 정답은 아니고, 실체는 배열인 varargs 매개변수를 List 매개변수로 바꿀 수도 있다. 이 방식을 앞서의 flatten 메소드에 적용한다면 다음처럼 된다.
1 2 3 4 5 6 7 | // 제네릭 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; } | cs |
정적 팩토리 메소드인 List.of를 활용하면 이 메소드에 임의 개수의 인수를 넘길 수 있는데, List.of에도 @SafeVarargs 애너테이션이 달려 있기 때문이다. 이 방식의 장점은 컴파일러가 이 메소드의 타입 안전성을 검증할 수 있다는 데 있다. 단점이라면 클라이언트 코드가 살짝 지저분해지고 속도가 조금 느려질 수 있다는 정도다.
가변인수와 제네릭은 궁합이 좋지 않다. 가변인수 기능은 배열을 노출하여 추상화가 완벽하지 못하고, 배열과 제네릭의 타입 규칙이 서로 다르기 때문이다. 제네릭 varargs 매개변수는 타입 안전하지는 않지만, 허용된다. 메소드에 제네릭 (혹은 매개변수화된) varargs 매개변수를 사용하고자 한다면, 먼저 그 메소드가 타입 안전한지 확인한 다음 @SafeVarargs 애너테이션을 달아 사용하는 데 불편함이 없게끔 하자.