다이아몬드 연산자(<>)는 자바 7에서 도입되었으며, 처음에는 익명 내부 클래스를 명시적으로 제외하고 오로지 구체적인 클래스 인스턴스 생성 표현식만 지원했습니다. 개발자들이 new Comparable<String>() { ... }와 같은 구성을 시도할 때, 컴파일러는 다이아몬드 변형인 new Comparable<>() { ... }를 거부했습니다. 이는 익명 클래스가 추론된 타입 매개변수를 참조하는 타입 멤버를 도입할 수 있어 불안정한 타입 시스템을 초래할 가능성이 있었기 때문입니다.
핵심 문제는 비표기 가능한 타입에 있었습니다. 익명 클래스는 클래스의 타입 매개변수에 의존하는 메소드나 필드를 선언할 수 있습니다. 만약 컴파일러가 다이아몬드에 대해 복잡한 교차 타입을 추론할 경우, 익명 클래스가 void foo(Box<T> t) {}를 선언하는 것과 같은 문제적인 시나리오에서 타입 T는 소스 코드로 표현할 수 없는 포획된 와일드카드를 나타낼 수 있습니다. 이는 익명 클래스의 API에 이름을 붙이거나 체크할 수 없는 타입이 포함되는 상황을 초래하여, 모든 공개 API의 타입이 명시적으로 표현 가능해야 한다는 자바의 근본적인 요구사항을 위반하게 됩니다.
자바 9는 JEP 213을 통해 이를 해결하는 데 표기 가능한 타입 분석을 구현했습니다. 이제 컴파일러는 익명 클래스 인스턴스화에 대해 추론된 타입이 표기 가능하도록 확인합니다. 다음 예시는 합법적인 사용을 보여줍니다:
// 자바 9+에서 유효 Comparator<String> c = new Comparator<>() { @Override public int compare(String a, String b) { return a.length() - b.length(); } };
만약 추론이 와일드카드나 표현할 수 없는 교차를 포함한 복잡한 타입을 생성하면, 컴파일러는 명시적인 타입 인수를 요구하도록 되돌아갑니다. 이는 일반적인 경우에 대해 간결한 구문을 허용하면서 타입 안전성을 보장합니다.
자바 8로 구축된 금융 거래 플랫폼에서 개발 팀은 수천 개의 이벤트 핸들러를 유지 관리했습니다. 이러한 핸들러는 주문 일치 엔진 전체에서 익명 구현 Comparator<TradeEvent> 및 **Predicate<MarketData>**를 사용했으며, 이는 코드 리뷰 중에 상당한 시각적 잡음을 발생시켰습니다.
팀은 보일러플레이트를 줄이기 위해 세 가지 접근 방식을 고려했습니다. 첫 번째 접근 방식은 모든 익명 클래스를 람다 표현식으로 마이그레이션하는 것이었습니다. 이는 간단한 경우에 대한 장황함을 제거했지만, 많은 핸들러는 람다의 기능을 초과하는 개인 헬퍼 메소드 또는 예외 처리 블록을 요구했습니다. 이러한 제한으로 인해 이름이 있는 내부 클래스로의 불편한 리팩토링이 강요되었고, 클래스 수는 증가하고 동작의 지역성은 감소했습니다.
두 번째 접근 방식은 명시적인 타입 인수를 유지하는 것이었습니다. 이는 전체 기능을 보존하고 기존 자바 8 인프라와 함께 작동했지만, 유지 보수 부담을 영속적으로 만들었습니다. 개발자들은 타입 서명이 변경될 때 반복적으로 병합 충돌을 경험했으며, 중복된 선언은 디버깅 세션 동안 인지 부하를 증가시켰습니다.
세 번째 접근 방식은 자바 9로 업그레이드하여 익명 클래스에 대한 다이아몬드 연산자 지원을 활용하는 것이었습니다. 마이그레이션 비용을 생산성 향상과 비교한 결과, 팀은 플랫폼이 기본적으로 Jigsaw 모듈 시스템 통합이 필요했기 때문에 자바 9 업그레이드를 선택했습니다. 표기 가능한 타입 분석을 통해 그들은 new Comparator<>() { public int compare(TradeEvent a, TradeEvent b) { ... } }와 같이 작성할 수 있었고, 컴파일러는 TradeEvent가 표기 가능한 타입임을 확인했습니다.
이 변경 사항은 평균 핸들러 정의를 네 줄에서 한 줄로 줄여 약 2,400줄의 중복 타입 선언을 제거했습니다. 따라서 기능 브랜치 전반에 걸쳐 명시적인 타입 인수를 동기화할 필요성을 없애면서 제너릭이 많은 모듈에서의 병합 충돌이 크게 감소했습니다. 이후 분기에서 개발 속도가 15% 향상되었습니다.
왜 다이아몬드 연산자가 원시 타입의 제네릭 생성자에 대한 타입 인수를 추론할 때 실패하는가?
new ArrayList()<>와 같은 원시 클래스를 인스턴스화할 때, 다이아몬드 연산자는 타입 인수를 추론할 수 없습니다. 이는 원시 타입이 제네릭 정보를 완전히 지우기 때문입니다. 컴파일러는 원시 타입이 타입 매개변수가 없는 것으로 취급하므로, 생성자 서명 자체가 매개변수를 잃어버려 추론이 불가능해집니다. 후보자들은 이 문제를 검사되지 않은 변환 경고와 혼동하는 경우가 많지만, 근본적인 문제는 원시 타입 컨텍스트에서 제네릭 메타데이터의 완전한 지워짐과 관련이 있으며, 단순히 검사되지 않은 작업과는 다른 문제입니다.
폴리 표현식과 다이아몬드 연산자 간의 상호 작용이 메소드 오버로드 해상도에 어떤 영향을 미치는가?
다이아몬드 연산자는 할당 컨텍스트에 따라 타입이 결정되는 폴리 표현식을 생성합니다. process(new ArrayList<>())와 같은 메소드 호출 컨텍스트에서, 컴파일러는 타입 추론을 완료하기 전에 메소드의 공식 매개변수로부터 타겟 타입을 결정해야 합니다. 이는 양방향 종속성을 생성합니다: 메소드의 적용 가능성은 추론된 타입에 의존하지만, 추론된 타입은 타겟 타입에 의존합니다. 컴파일러는 제약 생성 및 통합 단계를 통해 이를 해결하며, 이는 명시적인 타입 인수로 발생할 수 있는 타입과 다른 오버로드를 선택할 수 있습니다. 후보자들은 오버로드 해상도가 전체 타입 추론 전 발생한다는 점을 자주 간과하여, 여러 오버로드가 일치할 수 있는 경우에 놀라운 컴파일 타임 오류를 초래합니다.
배열 생성에서 표기 가능한 타입 제한과 재확인 가능한 타입 요구사항의 차이는 무엇인가?
두 가지 제한 모두 특정 제네릭 작업을 방지하지만, 표기 가능한 타입(다이아몬드 연산자 추론과 관련됨)은 타입이 소스 코드에서 표현될 수 있도록 보장하는 반면, 재확인 가능한 타입(즉, new T[10]과 관련됨)은 런타임 타입 정보를 요구합니다. List<String>와 같은 타입은 표기 가능하지만 재확인 가능하지 않습니다. 후보자들은 이 제약을 혼동하여 비표기 가능한 타입이 배열 저장 예외와 유사한 런타임 안전 위험을 초래한다고 믿는 경우가 많습니다. 하지만 실제로 비표기 가능한 타입은 소스 수준의 타입 표현 가능성과 API의 일관성을 손상시키며, 비재확인 가능한 타입은 런타임 타입 안전성을 손상시킵니다. 이러한 구별을 이해하는 것은 익명 클래스와 배열 기반 레거시 코드와 호환성을 유지해야 하는 제네릭 API를 설계할 때 매우 중요합니다.