질문에 대한 답변.

질문의 역사.

Java 5가 매개변수화된 타입을 도입하면서, 언어는 제네릭 이전에 컴파일된 레거시 코드와 이진 호환성을 유지하기 위해 타입 지우기를 채택했습니다. 이 설계 결정은 JVM 수준에서 모든 제네릭 타입 매개변수가 괄호로 묶인 경계—일반적으로 Object—로 대체되어 실제 타입 인수에 대한 런타임 흔적이 남지 않도록 했습니다. 결과적으로, 구체 클래스가 Comparable<String>과 같은 인터페이스를 구현할 때, 지워진 시그니처인 compareTo는 compareTo(Object)가 되며, 구현 클래스는 compareTo(String)를 선언합니다. 개입이 없으면 JVM은 이러한 메서드를 연결하지 못하고 서로 다른 개체로 취급하여 다형적 재정의를 허용하지 않습니다.

문제.

핵심 문제는 컴파일된 클라이언트 코드와 구현 클래스 간의 이진 호환성 부족으로 나타납니다. 제네릭 인터페이스에 대해 컴파일된 클라이언트 코드는 원시 시그니처의 메서드를 기대하지만(예: compareTo(Object)), 구현 클래스는 특정 시그니처만 제공합니다(예: compareTo(String)). 런타임에서 JVM은 상수 풀의 설명자를 기반으로 메서드 디스패치를 수행합니다. 만약 설명자 (Ljava/lang/Object;)I이 구체적인 구현과 일치하지 않으면, 가상 머신은 AbstractMethodError를 던지거나 잘못된 메서드를 호출하게 됩니다. 이 간극은 제네릭 인터페이스에 대해 진정한 다형적 동작을 방해하고, 지워진 계약과 특정 구현을 조정하기 위한 메커니즘이 필요하게 됩니다.

해결책.

Java 컴파일러는 구현 클래스 내에 지워진 원시 시그니처를 가진 합성 브리지 메서드를 생성하여 이를 해결합니다. 이 브리지 메서드는 바이트코드에서 ACC_BRIDGE와 ACC_SYNTHETIC 접근 플래그로 표시되어, 컴파일러에 의해 생성되었으며 소스 코드에는 존재하지 않음을 나타냅니다. 브리지 메서드는 단순히 인수를 특정 타입으로 unchecked 캐스팅하고 실제 메서드를 호출하여 실제 구현으로 위임합니다. 이 위임은 JVM의 메서드 해상도 알고리즘이 런타임에 일치하는 설명자를 찾아내도록 보장하며, 브리지 내의 캐스트는 컴파일 타임에 검증된 타입 안전성 제약을 강제합니다.

interface Node<T> {
    void setData(T data);
}

class StringNode implements Node<String> {
    @Override
    public void setData(String data) {
        System.out.println(data.toLowerCase());
    }
}

위의 예에서, 컴파일러는 StringNode 내에 public void setData(Object data)라는 합성 메서드를 생성하여 인수를 String으로 캐스팅하고 실제 setData(String)를 호출합니다.

실제 상황

문제 설명.

콘텐츠 관리 시스템을 위한 모듈식 플러그인 아키텍처를 설계하는 동안, 우리는 이벤트에 대해 플러그인이 타입별 핸들러를 구현할 수 있는 EventHandler<T> 인터페이스가 필요했습니다. 원시 타입을 사용하는 초기 프로토타입은 작동했지만, 제네릭으로 마이그레이션하는 동안 동적으로 로드된 플러그인 클래스가 이벤트 버스가 제네릭 인터페이스를 통해 이벤트를 전달하려 할 때 때때로 AbstractMethodError를 발생시켰습니다. 이 문제는 특정 JDK 버전과 복잡한 클래스 로더 계층에서만 나타났고, 일관되게 재현하기 어려웠습니다.

고려된 다양한 해결책.

한 가지 접근 방식은 제네릭을 완전히 제거하고 원시 Object 타입을 사용하며 각 핸들러 구현 내에서 수동 instanceof 검사를 수행하는 것이었습니다. 이 전략은 다양한 JDK 버전 간에 폭넓은 호환성을 제공하고 합성 메서드 복잡성을 완전히 회피했습니다. 그러나 컴파일 타임 타입 안전성을 희생시키며 개발자들은 런타임에 ClassCastException에 취약한 보일러플레이트 캐스팅 로직을 작성해야 했습니다. 이벤트 유형의 수가 증가함에 따라 유지 관리 부담은 크게 증가했고, 코드는 실제 타입 오류를 숨기는 unchecked 경고로 대량으로 어지러워졌습니다.

다른 대안은 java.lang.reflect.Proxy를 사용하여 동적으로 런타임에 프록시를 생성하여 메서드 호출을 가로채고 타입 적응을 자동으로 수행하는 것이었습니다. 이 솔루션은 플러그인 작성자에게 타입 안전성을 보장하면서 지워짐 불일치를 내부적으로 처리했습니다. 불행히도, 프록시 접근법은 리플렉션 및 메서드 호출 오버헤드로 인해 상당한 성능 오버헤드를 초래하였고, 스택 트레이스에 간접성을 추가하여 디버깅을 복잡하게 만들었습니다. 또한 이벤트 버스는 프록시 인스턴스와 실제 플러그인 인스턴스 간의 복잡한 매핑 로직을 유지해야 하므로 메모리 발자국이 증가했습니다.

선택된 솔루션은 컴파일러의 브리지 메서드 생성을 수용하여 모든 플러그인 인터페이스가 적절히 제네릭하고 구현 클래스가 Java 5+ 컴파일러로 컴파일되도록 보장했습니다. 우리는 ASM을 사용하여 컴파일된 플러그인 클래스에 브리지 메서드가 존재하는지 확인하는 바이트코드 검증 테스트를 추가했습니다. 이 접근 방식은 제로 런타임 오버헤드를 유지하고 전체 타입 안전성을 보존하며, 맞춤형 클래스 로더 조작 없이 표준 Java 컴파일 관행과 정렬되었습니다.

어떤 해결책이 선택되었고 그 이유는 무엇인가?

우리는 컴파일러의 보장된 동작을 활용하는 표준 브리지 메서드 접근 방식을 선택했습니다. 수동 캐스팅과 달리 합성 브리지의 캐스를 통해 호출 사이트에서 타입 제약을 강제하며, 타입 안전성이 위반되면 ClassCastException으로 빠르게 실패합니다. 동적 프록시에 비해 리플렉션 오버헤드를 제거하고 깔끔하고 해석 가능한 스택 트레이스를 유지합니다. 이 솔루션은 런타임 오버HEAD를 최소화하면서 컴파일 타임 검증을 극대화하는 우리의 목표와 일치했습니다.

결과.

적절한 제네릭 선언을 시행하고 컴파일 타임 바이트코드 검증을 추가한 후, AbstractMethodError 사건이 완전히 중단되었습니다. 플러그인 개발자는 이벤트 버스가 수동 캐스팅 없이 이벤트를 올바르게 라우팅할 것이라는 충분한 확신을 가지고 EventHandler<UserLoginEvent>를 구현할 수 있었습니다. 아키텍처는 타입 안전 사고 없이 50개 이상의 개별 이벤트 유형을 지원하도록 확장되었으며, 성능 프로파일링에 따르면 합성 메서드에 의한 측정 가능한 오버헤드가 없음을 확인했습니다.

후보자들이 자주 간과하는 점

리플렉션이 브리지 메서드와 실제 구현 메서드를 어떻게 구분할 수 있으며, 이 구분이 동적으로 메서드를 호출할 때 왜 중요한가?

java.lang.reflect.Method를 사용할 때 후보자들은 종종 getDeclaredMethods()가 소스 수준의 메서드만 반환한다고 가정합니다. 실제로는 합성 브리지 메서드도 포함되어 있어 필터링하지 않으면 중복 호출이나 잘못된 논리를 초래할 수 있습니다. Method 클래스는 이러한 컴파일러 생성 아티팩트를 식별하기 위해 isBridge() 및 isSynthetic() 조건자를 제공합니다. 이러한 플래그를 검사하지 않으면 브리지 메서드가 반사적으로 호출 될 때 무한 재귀가 발생할 수 있으며, 이는 대상을 호출하는 루프에서 다시 호출될 수 있습니다.

왜 비제네릭 클래스에서 공변 반환 타입 또한 브리지 메서드를 생성하며, 이것이 synchronized 수정자와 어떻게 상호작용하는가?

후보자들은 브리지 메서드가 제네릭 전용이 아니라는 점을 간과하는 경우가 많습니다. 공변 반환 타입을 오버라이드 할 때도 나타납니다(공변 반환). 예를 들어, 부모가 Number를 반환하고 자식이 Integer로 오버라이드하는 경우, Number를 반환하는 브리지 메서드가 생성됩니다. 중요한 세부사항은 synchronized 수정자가 브리지 메서드에 복사되지 않는다는 점입니다. 왜냐하면 JVM 락이 브리지의 프레임에서 획득되기 때문이므로 실제 구현의 쓰레드 안전성 추정이 깨질 수 있습니다. 이는 브리지 메서드가 자체적인 동기화 의미가 없는 단순 포워딩 스텁이라는 사실을 이해해야 합니다.

제네릭 인터페이스 메서드가 가변 인수 매개변수로 오버라이드 될 때 어떤 일이 발생하며, 브리지 메서드는 바이트코드 수준에서 배열과 가변 인수의 구분을 어떻게 처리하는가?

이 시나리오는 지워진 시그니처가 배열 타입(Object[])을 사용하고 구현이 가변 인수를 사용할 때 복잡한 브리지를 생성합니다. 컴파일러는 가변 인수 메서드를 호출하는 Object[]을 수용하는 브리지 메서드를 생성합니다. 후보자들은 가변 인수 메서드가 바이트코드 수준에서 배열 매개변수로 컴파일되므로, 브리지가 실제 메서드와 설명자에서 동일하게 보인다는 것을 간과합니다. 그러므로 컴파일러는 그들을 구별하기 위해 추가 로직을 생성하거나 ACC_VARARGS 플래그를 사용해야 합니다. 이를 이해하지 못하면, 배열 인수를 보여주는 스택 추적을 분석할 때 또는 설명자 일치 복잡성 때문에 그러한 메서드를 호출하기 위해 MethodHandle을 사용할 때 혼란이 발생할 수 있습니다.