반응형

1. 자바 제네릭의 한계?

자바 제네릭은 클래스에서 사용할 타입을 외부(사용부)에서 사용하게 해주는 일반적인 기법을 의미한다.

이러한 제네릭을 사용하면, 타입만 다르고 공통된 기능을 가지고 있는 클래스나 메서드들에 파라미터로 타입을 외부에서 전달받아 조금 더 범용적인 코드를 만들 수 있다. 이러한 제네릭이 없었다면, 자바 객체의 최고 조상인 Object 로 전달받아 객체 타입에 따라 캐스팅해 로직을 별도로 만들어야 되는데 이러면 오히려 런타임 시 예기치 못한 오류가 더 많이 발생하고 별도의 타입으로 만들어둔 클래스 및 함수들과 다를 바 없다.

 

public class Generic {
    public List<String> list = new ArrayList<>();

    public void addString(String str) {
        list.add(str);
    }

    public String getString(int index) {
        return list.get(index);
    }
}

// 제네릭이 아니라면, 이렇게 Object 로 전달
public class NonGeneric {
    public List list = new ArrayList();

    public void addString(Object obj) {
        list.add(obj);
    }

	// 원하는 타입으로 캐스팅 해 반환
    public String getString(int index) {
        return (String) list.get(index);
    }
}

 

그런데 자바 제네릭은 다른 언어의 제네릭과 달리 다른 점이 존재한다.

제네릭 도입 이후, 컴파일 타임 때까지는 타입 안전성을 얻을 수 있었지만, Type Erasure 기능으로 인해 컴파일 이후에는 타입이 소거가 되기 때문이다. 반쪽 제네릭이라고 불리우는 이유이다.

 

Class Test<T> {
	private T value;
    
    public Test(T t) {
    	this.value = t;
    }
    
    public T get() {
    	return value;
    }
}

// -> 컴파일 이후
Class Test {
	private Object value;
    
    public Test(Object t) {
    	this.value = t;
    }
    
    public Object get() {
    	return value;
    }
}

 

컴파일 타임 이후에 Object 로 변환이 된 것을 볼 수 있다. 컴파일 때까지만 타입 안전성을 제공하고, 그 이후에는 Object 로 변환이 되기 때문에 런타임 시에는 오류가 발생할 수도 있다.

 

자바 진영에서는 동세대 언어인 C# 과 다르게 보급률이 좋아서 현업 프로젝트들이 월등히 많았고 이러한 프로젝트들을 지키고자 하위 호완성을 위해 Type Erasure 를 도입했다고 한다. 컴파일 타임 때 Type Erasure 를 수행하면서 제네릭이 없던 하위 버전들과 동일한 형태로 class 파일을 생성할 수 있었다.

 

2. 타입 토큰의 등장

자바언어 개발자였던 Neal Gafter는 JAVA JDK5에 generics를 추가할 때 java.lang.Class 가 generic type이 되도록 변경했다고 한다. 예를 들어, String.class 의 Type 이 Class<String> 되도록 만들어 주었다. 그리고 이를 타입 토큰이라고 불렀다.

 

클래스 리터럴과 타입 토큰의 차이

클래스 리터럴은 어떤 클래스인지 파라미터로 전달되는 정보로 타입 토큰의 클래스 정보이다. 타입 토큰과 동일한 개념으로 타입 토큰은 클래스의 타입을 명시하고, 클래스 리터럴은 그 타입 토큰과 매칭되는 매개변수로 보면 된다.

 

// 선언부 (타입 토큰)
void myMethod(Class<?> clazz) {
	...
}
  
// 사용부 (클래스 리터럴)
myMethod(String.class);

 

이 타입 토큰은 컴파일 타임 이후에도 타입에 대한 안전성을 확보하고자 사용된다.

제네릭만 사용했을 때, Operation 이나 타입들의 메서드들이 동일해야 사용할 수 있다는 한계가 있긴 하지만 그래도 동일한 기능을 한 코드로 만들 수 있어 좋다. 그런데 원하는 타입으로 반환은 안 된다. 아까 위에서 언급한 것처럼 타입이 모두 Object 로 변환되기 때문에 타입 캐스팅이 되지 않는다. 이 때 타입 토큰이 유용하게 사용된다.

 

// 선언부
public <T> T readValue(String content, Class<T> valueType) {
	...
}

// 사용부
ProductDto productDto = objectMapper.readValue(jsonString, ProductDto.class);

 

위 예제처럼, valueType 으로 클래스 타입을 매개변수로 전달해주면 json 을 읽어 그 타입으로 반환해줄 수 있다.

조금 더 나아가 THC (Typesafe Heterogenous Container) Pattern 으로 사용될 수 있다.

 

// 선언부
public class SimpleTypeSafeMap {
	private Map<Class<?>, Object> map = new HashMap<>();
    public <T> void put(Class<T> k, T v) {
    	map.put(k, v);
    }
    public <T> T get(Class<T> clazz) {
    	return clazz.cast(map.get(clazz));
    }
}

// 사용부
simpleTypeSafeMap.put(String.class, "테스트");
simpleTypeSafeMap.put(Integer.class, 1);

String string1 = simpleTypeSafeMap.get(String.class);
Integer integer1 = simpleTypeSafeMap.get(Integer.class);

 

타입 토큰을 키로 사용해 타입끼리 저장하고 다시 그 타입 토큰으로 캐스팅해서 가져올 수 있다. 타입 안전 이종 컨테이너라고 불리우며 영어로는 THC (Typesafe Heterogenous Container) 라고 한다. 컨테이너가 타입을 체크해서 컴파일 여부를 결정하는 것이 아니라 타입 토큰을 가지고 프로그래머가 직접 핸들링하는 개념이다.

 

3. 슈퍼 타입 토큰의 등장

타입 토큰의 한계

이 타입 토큰에도 한계는 있다. 제네릭 타입의 클래스 리터럴과 타입 토큰은 존재하지 않는다. Type Erasure 때문에 <> 내부에 있는 타입들이 제거되기 때문이다. 조금 더 쉽게 생각해보면 이중 삼중... 다중 타입에 대한 정보들을 가지고 있지 않아서 그렇다. 이러한 타입 토큰의 한계를 극복한 개념이 슈퍼 타입 토큰이다.

 

슈퍼 타입 토큰

다중 타입에 대한 정보들을 리터럴로 표현할 수 있으면 타입 토큰처럼 안전성을 확보할 수 있을 것이다.

Class.getGenericSuperclass() 와 ParameterizedType.getActualTypeArguments() 를 사용해서 전체 타입에 대한 정보와 실제 타입을 가져올  수 있다.

 

class Super<T> {}
class MyClass extends Super<List<String>> {}

MyClass myClass = new MyClass();

Type typeOfGenericSuperclass = myClass.getClass().getGenericSuperclass();

// ~~~$1Super<java.util.List<java.lang.String>> 출력됨
System.out.println(typeOfGenericSuperclass);

 

Super 껍데기 클래스의 파라미터로 해당 타입을 전달하면 getGenericSuperclass 메서드로 전체 타입에 대한 정보를 가져올 수 있다. Class (Java Platform SE 8 ) (oracle.com)

 

Class (Java Platform SE 8 )

Determines if the specified Class object represents a primitive type. There are nine predefined Class objects to represent the eight primitive types and void. These are created by the Java Virtual Machine, and have the same names as the primitive types tha

docs.oracle.com

 

getGenericSuperclass 메서드에 대한 내용을 번역해보면 다음과 같다.

해당 객체의 상위 클래스 타입을 반환하는 메서드. 만약 상위 클래스가 매개변수화된 타입이라면 소스코드에서 사용된 실제 타입들을 반영해 반환해야 한다. 매개변수화된 타입에 대한 내용은 별도의 문서를 확인하라고 적혀 있다.(ParameterizedType은 제네릭 타입을 가지고 있는 타입을 말한다.)

ParameterizedType (Java Platform SE 8 ) (oracle.com)

 

ParameterizedType (Java Platform SE 8 )

ParameterizedType represents a parameterized type such as Collection<String>. A parameterized type is created the first time it is needed by a reflective method, as specified in this package. When a parameterized type p is created, the generic type declara

docs.oracle.com

 

제네릭 타입이라면, getActualTypeArguments 메서드를 통해 이 제네릭의 실제 타입을 가져올 수 있다.

 

class Super<T> {}
class MyClass extends Super<List<String>> {}

MyClass myClass = new MyClass();

Type typeOfGenericSuperclass = myClass.getClass().getGenericSuperclass();

// ~~~$1Super<java.util.List<java.lang.String>> 출력됨
System.out.println(typeOfGenericSuperclass);

// 수퍼 클래스가 ParameterizedType 이므로 ParameterizedType으로 캐스팅 가능
// ParameterizedType의 getActualTypeArguments()으로 실제 타입 파라미터의 정보를 구함
Type actualType = ((ParameterizedType) typeOfGenericSuperclass).getActualTypeArguments()[0];

// java.util.List<java.lang.String>가 출력됨
System.out.println(actualType);

 

슈퍼 타입 토큰 예제

// 선언부
public abstract class TypeReference<T> {
    private final Type type;

    protected TypeReference() {
    	Type superClassType = getClass().getGenericSuperclass();
        if (superClassType instanceof ParameterizedType) {
        	this.type = ((ParameterizedType)superClassType).getActualTypeArguments()[0];
        } else {
            throw new IllegalArgumentException("TypeReference는 항상 실제 타입 파라미터 정보가 있어야 합니다.");
        }
    }

    public Type getType() {
        return type;
    }
}

// 사용부
public class TypeSafeMap {
    private final Map<Type, Object> map = new HashMap<>();

    public <T> void put(TypeReference<T> k, T v) {
        map.put(k.getType(), v);
    }

    public <T> T get(TypeReference<T> k) {
        final Type type = k.getType();
        final Class<T> clazz;
        if (type instanceof ParameterizedType) {
            clazz = (Class<T>) ((ParameterizedType) type).getRawType();
        } else {
            clazz = (Class<T>) type;
        }
        return clazz.cast(map.get(type));
    }
}

 

Class.getGenericSuperclass() 와 ParameterizedType.getActualTypeArguments() 를 활용해서 실제 RawType 를 가져온다.

 

4. 프레임워크의 슈퍼 타입 토큰

이렇게 매번 직접 만들기에는 수고스럽다. 프레임워크에서도 이런 슈퍼 타입 토큰을 지원한다.

 

Spring 의  ParameterizedTypeReference

Spring 프레임워크에서도 동일하게 런타임 시 발생하는 타입 안정성 문제를 해결하기 위해 ParameterizedTypeReference라는 클래스를 만들었다. 매개변수화된 타입에 대한 정보를 가져올 때 사용하면 된다. 클래스 리터럴을 전달하는 대신 아래와 같이 사용하면 된다. new ParameterizedTypeReference<List<User>>()

 

spring-framework/ParameterizedTypeReference.java at main · spring-projects/spring-framework (github.com)

 

GitHub - spring-projects/spring-framework: Spring Framework

Spring Framework. Contribute to spring-projects/spring-framework development by creating an account on GitHub.

github.com

 

앞에서 살펴본 구현방식과 유사하다. 보통 다른 서버에서 자원을 가져올 때 사용한다고 한다.

ObjectMapper 에서는 ParameterizedTypeReference 를 사용하지 않고 직접 위에서 소개한 것처럼 구성하여 만들고, Spring Cloud feign 에서는 자체적으로 타입을 넘겨주지 않더라도 Reflection 기능을 통해 확인한다고 한다.

반응형

'JAVA' 카테고리의 다른 글

[JAVA] Stream Collector groupingBy  (0) 2023.02.26
반응형

ITEM 32 "제네릭과 가변인수를 함께 쓸 때는 신중하라"

 

가변인자는 매개변수의 개수가 정해지지 않은 함수의 인자를 말한다. 메서드에 넘기는 인자의 개수를 클라이언트가 조절할 수 있어, 인자의 개수만큼 메서드를 여러 번 오버라이딩하지 않고 원하는 개수만큼 인자를 넘길 수 있게 되었다.

가변인자를 정의할 때는 고정 매개변수가 하나 이상 있어야 하고, 고정 매개변수 뒤에 ... 을 붙여 개수가 정해져 있지 않다는 표시를 해주면 된다.

 

public static void example(String... args) {
    //....
}

 

 

가변인수 메서드를 호출하면 내부적으로 가변인수를 담기 위한 배열이 자동으로 하나 만들어진다. 하지만 내부로 감춰야되는 이 배열이 클라이언트에 노출된다는 문제점이 있다. 이 문제점 때문에 varargs 매개변수에 제네릭이나 매개변수화 타입이 포함되면 컴파일 경고가 발생하게 된다. 결론부터 말하자면, 배열과 제네릭을 같이 쓰기 때문이다.

 

이전 아이템에서 보았듯이, 제네릭과 같은 실체화 불가 타입은 런타임에 타입 관련 정보가 소거가 된다. 타입에 대한 정보가 없기 때문에 실체화 불가 타입으로 varargs 매개 변수를 선언하면 컴파일러가 아래와 같이 경고를 보내게 된다. 

 

warning: [unchecked] Possible heap pollution from
    parameterized varargs type List<String>

 

매개변수화 타입의 변수가 타입이 다른 객체를 참조할 가능성이 있게 되고 이는 힙 오염을 발생시키는 원인이 된다.

제네릭과 가변인수를 혼용하여 사용해서 타입 안전성이 깨진 예제를 살펴보자.

 

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

 

이전 아이템 28 "배열보다는 리스트를 사용하라" 편에서 나온 예제와 유사하다. 인자형태가 List<String> 타입을 배열의 아이템으로 가지고 있기 때문에 배열의 공변성과 제네릭의 불공변성이 충돌해 ClassCastException 예외가 발생하게 된다.

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

 

자바 7 이전에는 제네릭 가변인수 메서드의 작성자가 호출자 쪽에서 발생하는 경고에 대해서 해줄 수 있는 일이 없었다. 따라서 사용자는 이 경고들을 그냥 두거나 (더 흔하게는) 호출하는 곳마다 @SuppressWarnings("unchecked") 애너테이션을 달아 경고를 숨겨야 했었다.

 

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

 

그러나 메서드가 안전한 게 확실하지 않다면 @SafeVarargs 애너테이션을 달아서는 안 된다. varargs 배열에 아무것도 저장하지 않고 (그 매개변수들을 덮어쓰지 않고) 그 배열의 참조가 밖으로 노출되지 않는다면(신뢰할 수 없는 코드가 배열에 접근할 수 없다면) 타입 안전성이 보장될 때만 사용해야 한다. 예를 들어 아래와 같은 코드는 타입 안전하지 않다.

 

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

 

이 메서드가 반환하는 배열의 타입은 이 메서드에 인수를 넘기는 컴파일타임에 결정되는데, 그 시점에는 컴파일러에게 충분한 정보가 주어지지 않아 타입을 잘못 판단할 수 있다. T 배열이 Object 배열이고 String 타입과 Integer 타입이 toArray 인자로 전달된다고 가정해보자. Object 배열에 여러 가지 타입이 혼종되어 오염이 발생할 수 있다. 자신의 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 매개변수 배열이 만드는 코드를 생성한다. 여기서 중요한 점은 pickTwo에 어떤 타입의 객체를 넘기더라도 담을 수 있게 하기 위해 Object[] 배열로 반환된다. toArray() 메서드가 돌려준 Object[] 배열이 그대로 pickTwo()를 호출한 클라이언트까지 전달된다. pickTwo()는 항상 Object[] 타입 배열을 반환하게 된다.

 

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

 

위에서 작성했던 코드를 사용하면, ClassCastException 예외가 발생한다. pickTwo()의 반환값인 Object[] 배열을 String[] 타입의 attributes 에 저장하기 위해 String[] 로 형변환하는 코드가 컴파일러가 자동 생성하기 때문이다. 여기서 유의해야할 점은 해당 코드가 힙 오염을 발생시킨 진짜 원인인 toArray() 로부터 두 단계나 떨어져 있다는 점이다.

 

제네릭 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;
    }

 

위 코드가 타입 안전한 코드이다. @SafeVarargs 애너테이션을 사용했기 때문에 사용부에서도 문제없이 컴파일된다.

@SafeVarargs 애너테이션은 제네릭이나 매개변수화 타입의 Varargs 매개변수를 받는 모든 메서드에 추가하는 것이 좋다.

또한 @SafeVarargs 애너테이션은 재정의할 수 없는 메서드에만 달아야 한다. 재정의한 메서드도 안전할지는 보장할 수 없기 때문이다.

이 말인 즉슨, 타입 안전하지 않는 Varargs 메서드는 작성하면 안 된다는 것이기 때문에 개발자가 해당 메서드들이 타입 안전하도록 모두 보장해야 한다는 것이다.

 

첫 번째, Varargs 매개변수 배열에는 아무것도 저장하지 않는다.

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

 

아니면, 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 애너테이션이 달려 있기 때문에 가능하다.

 

audience = flattern(List.of(frends, romans, countrymen));

 

이 방식은 컴파일러가 이 메서드의 타입 안전성을 검증할 수 있다는 장점이 있다. @SafeVarargs 애너테이션을 직접 달지 않아도 되며, 실수로 안전하다고 판단할 염려도 없게 된다. 하지만 클라이언트 코드가 길어지고, 속도가 조금 느려질 수 있다.

 

이 방식을 위 pickTwo 메서드에 적용하면 다음과 같다.

 

    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(); // 도달할 수 없다.
    }
    public static void main(String[] args) {
        List<String> attributes = pickTwo("좋은", "빠른", "저렴한");
    }

 

"가변인수는 내부적으로 배열을 사용하기 때문에 제네릭과 같이 사용하면 안 된다.

하지만 자바 언어에서허용하고 있다. 그 메서드가 타입 안전하게 만들고 (가변인자 배열에 저장하지 않고, 신뢰할 수 없는 코드에 노출하지 않는다.) @SafeVarargs 어노테이션을 붙여 불편함을 없애자"

반응형
반응형

ITEM 27 "비검사 경로를 제거하라"

 

제네릭을 사용하기 시작하면, 수많은 컴파일러 경고를 보게 된다.

비검사 형변환 경고, 비검사 메서드 호출 경고, 비검사 매개변수화 가변인수 타입 경고, 비검사 변환 경고 등 수많은 비검사 경고들을 볼 수 있다. 비검사 경고란, 컴파일 시에 컴파일러가 자바 코드를 컴파일하고 나서 잘못된 것들에 대해 경고하는 옵션을 의미한다. javac 명령 인수에 -Xlint:uncheck 를 추가하면 해당 에러를 볼 수 있다.

 

public class EffectiveJavaTest {
    static class Test {
        Test() {}
    }
    static Set<Test> testSet = new HashSet();
    public static void main(String[] args) {
        testSet.add(new Test());
    }
}

 

위 코드를 -Xlint:unchecked 옵션과 함께 컴파일하면 unchecked conversion 경고가 발생한다. HashSet 에 다이아몬드 연산자를 추가해 실제 타입 매개변수를 추론해야만 경고가 사라진다. 이렇게 가능한 모든 비검사 경로를 제거해야 한다. 그래야 런타임 시에 ClassCastException 이 발생할 일이 없고, 의도한 대로 잘 동작할 수 있다.

 

경고를 제거할 수는 없지만, 타입 안전하다고 확신할 수 있다면 @SuppressWarnings("unchecked") 애너테이션을 달아 경고를 숨기자. 단, 애너테이션을 다는 개발자가 직접 타입 안전함을 검증하지 않은 채 경고를 숨기면 경고 없이 컴파일은 되겠지만, 런타임시에 ClassCastException 이 발생할 수 있다.

 

@SuppressWarnings 애너테이션은 개별 지역변수 선언부터 클래스 전체까지 어떤 선언에도 달 수 있다. 하지만 가능한 좁은 범위에 적용해야 된다. 변수 선언이나 짧은 메서드, 생성자에 적용해야 한다. 어디에서 경고가 발생할지 모르니 절대 클래스 전체에 적용하면 안 된다.

 

public class EffectiveJavaTest {
    // 수정 전
    public <T> T[] toArray(T[] a) {
        if (a.length < size)
            return (T[]) Arrays.copyOf(elements, size, a.getClass());
        System.arraycopy(elements, 0, a,0, size);
        if (a.length > size)
            a[size] = null;
        return a;
    }
    
    // 수정 후
    public <T> T[] toArray(T[] a) {
        if (a.length < size) {
            @SuppressWarnings("unchecked")
            T[] result = (T[]) Arrays.copyOf(elements, size, a.getClass());
            return result;
        }
        System.arraycopy(elements, 0, a,0, size);
        if (a.length > size)
            a[size] = null;
        return a;
    }
}

 

수정 전 코드를 보면 Arrays.copyOf 메서드에 unchecked cast 경고가 발생한다. 애너테이션은 선언에만 달 수 있기 때문에 return 구문에 적용할 수 없다. 그래서 return 지역 변수를 하나 만들고 그 변수에 애너테이션을 만들어야 한다. 범위도 줄일 수 있고 깔끔해진다. 애너테이션을 사용할 때면 그 경고를 무시해도 안전한 이유를 항상 주석으로 남기자.

반응형
반응형

ITEM 26 "로 타입은 사용하지 말라"

 

같은 기능을 하는 코드이지만 자료형에 따라 오버로딩 함수를 여러 개 만들어야 한다고 생각해보자.

자연스레 타입에 상관없이 제네릭하게 코드를 구성하고 싶을 것이다. 자바에서도 타입을 매개변수로 하여 클래스와 인터페이스를 작성할 수 있으며 제네릭 클래스 혹은 제네릭 인터페이스라고 한다. 두 정의를 통틀어 제네릭 타입이라 한다.

 

꺽쇠괄호 안에 실제 타입 매개변수들을 나열해서 매개변수화 타입을 정의한다. 예를 들어 List<String> 과 같은 식이다.

이 제네릭 타입을 정의하면 로 타입도 함께 정의되는데 이 로 타입을 주의해야 한다. List<String> 의 로 타입은 List 이다. 선언 시에 타입에 대한 정보가 지워진 것처럼 동작하는데 하위 호환성을 위해 자바 9 까지 계속 허용하고 있다.

 

public class EffectiveJavaTest {
    static class Stamp {
        public Stamp () {}
        public void cancel() {}
    }
    static class Coin {
        public Coin () {}
    }
    private final static Collection stamps = new ArrayList<>();

    public static void main(String[] args) {
        stamps.add(new Coin());
        for (Iterator i = stamps.iterator(); i.hasNext();) {
            Stamp stamp = (Stamp) i.next();
            stamp.cancel();
        }
    }
}

 

선언 시에 타입에 대한 정보가 없으니 아무런 원소를 넣어도 컴파일 오류가 발생하지 않는다. 위 코드처럼 반복자로 원소를 비교하거나 꺼낼 때 런타임 오류가 발생한다. 원소 추가는 Coin 클래스로, 원소 활용은 Stamp 클래스로 할 수 있는 것을 볼 수 있다. 항상 느끼지만 자유도가 높으면 프로그래머의 실수를 유발하는 것 같다.

 

Collection<Stamp> 로 타입을 지정해준다면, 컴파일 타임 때 오류를 발견할 수 있다. 런타임 오류의 경우, 문제 발생 코드와 원인을 제공하는 코드가 물리적으로 상당히 떨어지면 어디서 오류가 발생했는지 모든 소스코드를 다 뒤져야 할 수도 있다. 그런데 컴파일 타임 때 오류를 발생하면 타입 안전하게 코드를 작성할 수 있다.

 

정말 로 타입을 쓰고 싶다면, List<Object> 처럼 임의의 객체를 허용하는 매개변수화 타입을 권장하고 있다.

매개변수로 List 를 받는 메서드에 List<String> 을 넘길 수 있지만, List<Object> 를 받는 메서드에는 넘길 수 없다.

 

더 나아가, 원소의 타입을 몰라도 되는 로 타입을 쓰고 싶을 때 <?> 비한정적 와일드카드를 쓸 것을 권장하고 있다.

<?> 는 < ? extends Object > 의 줄임 표현으로 어떤 자료형의 객체도 매개변수로 받겠다는 의미이다. 로 타입하고 같아보이지만, 처음에 넣은 타입 외에는 다른 원소를 넣을 수 없다는 특징이 있다.

 

public class EffectiveJavaTest {
    private static int test(Set<?> s1, Set<?> s2) {
        s1.add("test");
    }
    public static void main(String[] args) {
        Set<Integer> s1 = new HashSet<>();
        s1.add(Integer.valueOf(10));
        Set<Integer> s2 = new HashSet<>();
        s2.add(Integer.valueOf(20));
        test(s1, s2);
    }
}

 

< ? extends Object > 라고 많은 블로그에서 정의하고 있지만 사실 상 <? extends 입력된 첫번째 자료형> 이지 않을까 싶다. 그대로 컴파일하면 아래와 같은 에러를 내뿜는다. Integer 용 Set 에 String 을 add 하기 때문에 타입 컨벤션 오류가 발생한 것이다.

 

error: incompatible types: String cannot be converted to CAP#1
        s1.add("test");
               ^
  where CAP#1 is a fresh type-variable:
    CAP#1 extends Object from capture of ?

 

컴파일 단계 때, 타입 검사를 할 수 있어 로 타입보다 더 좋아보이지만 extends 와 super 키워드 없이 (상한제한자, 하한제한자) 단독으로 사용하지 않을 것을 권장하고 있다. 자세한 내용은 아래 링크를 참조하는 것을 추천한다. 

사용법 - Java에서 클래스 <?>은 무엇을 의미합니까? - 스택 오버플로 (stackoverflow.com)

 

그렇다고 로 타입을 아예 안 쓰지는 않는다. 로 타입을 써야되는 경우는 두 가지이다.

class 리터럴에는 로 타입을 써야 한다. 어떤 클래스를 표현하고자 할 때 xxx.class 로 표기하는데 여기에 제네릭 타입을 쓰면 안 된다. 두 번째는 instanceof 연산자이다. instanceof 연산자의 비연산자도 굳이 제네릭 타입을 쓸 필요가 없다.

 

"로 타입은 지양하자."

반응형

+ Recent posts