본문 바로가기

Dev Book Review/Effective Java

[Effective Java] item32. 제네릭과 가변인수를 함께 쓸 때는 신중하라

1. 가변인수와 제네릭을 함께 사용할 때의 헛점

가변인수 메서드를 호출하면 가변인수를 담기위한 배열이 자동으로 하나 만들어진다.
내부로 감춰야했을 배열을 클라이언트에 노출해서 문제가 생겼다.

제네릭타입의 가변인수 메서드를 호출하면, 제네릭 타입의 배열이 생성되며, 제네릭 타입의 배열은 item28에서 말한 것 처럼, 타입을 런타임에 체크하기 때문에 클래스 캐시팅 에러가 날 가능성이 있다.

메서드 선언시, 실체화 불가 타입으로 varargs 매개변수를 선언하면 컴파일러가 경고를 보낸다.

image

힙오염이 가능하기 때문이다.

제네릭과 varages를 혼용하면 타입 안정성이 깨진다. 따라서 제네릭 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
}

이런 위험에도 varargs 매개변수를 받으면 메서드가 실무에서 매우 유용하다.

Arrays.asList(T... a), Collections.addAll(Collection<? superT> c, T... elements),EnumSet.of(E first, E... rest)

2. @SafeVarargs 애너테이션

a. @SuppressWarnings("unchecked")

호출하는 곳 마다 이 애너테이션을 달아 경고를 숨겨야했다.

지루하고, 가독성을 떨어드리고, 때로는 진짜 문제를 알려주는 경고마저 숨긴다.

b. @SafeVarargs

메서드 작성자가 그 메서드가 타입 안전함을 보장하는 장치

컴파일러가 이 약속을 믿고 이 메서드가 안전하지 않을 수 있다는 경고를 더이상 하지 않는다.

3. 메서드가 안전한지 확신 할 수 있을 때

  • 메서드가 varargs 매개변수를 담는 배열에 아무것도 저장하지 않을 때
  • varargs 배열의 참조가 밖으로 노출 되지 않을 때

즉, 순수하게 인수들을 전달하는 일만 할 때 메서드가 안전하다.

4. 제네릭 varargs 매개변수 배열에 다른 메서드가 접근하도록 허용하지 말자

자신의 제네릭 매개변수 배열의 참조를 노출하므로 안전하지 않다.

  • 힙 오염을 메서드를 호출한 쪽의 콜스택으로까지 전이하는 결과를 낳는다.
static <T> T[] toArray(T... args){
  return args; // 참조가 밖으로 
}

예외사항

a. @SafeVarargs로 제대로 애노테이트 된 또다른 varargs 메서드에 넘기는건 안전하다.

b. 이 배열 내용의 일부 함수를 호출만 하는(varargs를 받지 않는) 일반 메서드에 넘기는 것도 안전하다.

5. varargs 매개변수를 List 매개변수로 바꿀 때

static <T> List<T> flatten(List<List<? extends T>> lists){
  List<T> restul = new ArrayList<>();
  for(List<? extends T> list : lists)
    result.addAll(list);
  return result;
}
  • 컴파일러가 이 메서드의 타입 안전성을 검증할 수 있다.
  • @SafeVarargs 애너테이션을 달지 않아도 된다.
  • 실수로 안전하다고 판단할 걱정도 없다.
  • 기존의 varargs는 배열로 메서드의 타입 안정성 검증이 불가능 했었다.