프로젝트 발할라, 야심찬 자바 리팩터의 내부 들여다보기

문제 1 : 메서드 호출과 값에 의한 전달

메모리에서 객체의 기본 구조는 메모리와 캐싱, 두 가지 모두에 비효율적이다. 또한 메서드 호출 규약에서 이득을 얻을 기회가 있다. 값에 의한 호출 인수를 클래스 구문으로 (적절한 경우) 메서드에 전달할 수 있으면 상당한 성능 혜택을 얻을 수 있다.
 

문제 2 : 박스와 오토박싱

비효율성 외에, primitive와  class의 구분은 언어 수준의 어려움을 일으킨다. Integer 및 Long과 같은 프리미티브 “박스”를(오토박싱과 함께) 만드는 것은 이 구분에 의해 발생하는 문제를 완화할 수 있는 방법이다. 그러나 문제를 실제로 해결하는 것은 아니고 개발자와 머신에 모두 일정한 오버헤드도 유발한다. 개발자는 int와 Integer, ArrayList<Integer>, int[], Integer[]의 차이, 그리고 ArrayList<int>의 부재에 대해 알고 유의해야 하고, 머신은 이 둘을 상호 변환해야 한다.
 
어떤 면에서 박싱은 두 가지 영역의 가장 좋지 않는 부분을 제공한다. 이러한 엔터티의 근본적인 작동 방식을 알아보기 어렵게 하는 것은 클래스 구문의 강력함과 프리미티브 성능, 두 가지 모두를 더 멀어지게 하는 결과를 초래한다.
 

문제 3 : 제네릭과 스트림

이러한 모든 고려 사항은 제네릭에서 정점에 이른다. 제네릭의 목적은 기능 전반의 일반화를 쉽게, 더 명시적으로 하는 데 있지만 이 비객체 변수(프리미티브)의 까다로운 존재가 제네릭을 망친다. <int>는 존재하지 않는다. int가 클래스가 아니기 때문에 존재할 수가 없고, Object의 자손이 아니다.
 
이 문제는 제네릭 라이브러리 함수가 가진 이상이 IntStream 및 기타 비제네릭 변형을 제공함으로써 int 대 Integer, long 대 Long과 같은 현실에 대처해야 하는 컬렉션 및 스트림과 같은 라이브러리에 그대로 나타난다.
 

발할라의 해법 : 값 클래스와 프리미티브 형식

프로젝트 발할라는 뿌리에서 문제 해결을 모색한다. 첫 번째이며 가장 근본적인 개념은 값 클래스다. 핵심 개념은 메서드, 제네릭 실행 기능과 같은 클래스의 모든 장점을 갖지만 동일성은 없는 클래스를 정의할 수 있다는 것이다. 실무 관점에서 이 말의 의미는 클래스는 변경할 수 없고 레이아웃 다형성을 가질 수 없다는 것이다(슈퍼클래스는 추상화 속성을 통해 서브클래스에 대해 동작이 가능함).

값 클래스는 클래스 구문과 동작의 이러한 이점을 그대로 이용하면서 우리가 추구하는 성능 특성을 얻는 명확하고 결정적인 방법을 제공한다. 즉, 라이브러리 빌더도 이를 사용함으로써 API 설계를 개선할 수 있다.
 
여기서 한 걸음 더 나간 것이 더 극단적인 값 클래스라고 할 수 있는 프리미티브 클래스다. 기본적으로 프리미티브 클래스는 실제 프리미티브 변수를 감싸는 얇은 래퍼지만 클래스 메서드가 있다. 간소화된 맞춤형 프리미티브 박스와 같다. 개선된 부분은 박싱 시스템을 더 명시적으로, 더 확장 가능하게 한다는 점이다. 또한 프리미티브 클래스로 래핑된 프리미티브 값은 프리미티브의 성능 특성을 그대로 보존한다(내부적인 박싱과 언박싱이 없음). 따라서 클래스를 사용할 수 있는 모든 곳(예를 들어 Object[] 배열)에서 프리미티브 클래스를 사용할 수 있다. 프리미티브 형식은 null이 될 수 없다(null로 설정할 수 없음).
 
대체로 프로젝트 발할라는 프리미티브와 사용자 정의 형식을 서로 더 가까이 근접시킨다고 할 수 있다. 이는 개발자에게 순수 프리미티브와 객체 사이의 스펙트럼에서 더 많은 옵션을 제공하고 타협을 명확하게 드러나게 한다. 또한 전반적으로 이러한 작업의 일관성을 높여준다. 특히 새로운 프리미티브 시스템은 프리미티브와 객체의 작동 방식, 박싱되는 방식, 새 항목을 추가하는 방식을 매끄럽게 다듬는다.
 

자바의 구문은 어떻게 바뀌는가

발할라에는 지금까지 여러 구문이 제안됐지만 현재 프로젝트의 형식과 방향은 명확하다. value와 primitive, 두 가지 새로운 키워드는 class 키워드를 수정한다. value class 구문으로 선언되는 클래스는 동일성을 포기하며, 그 과정에서 성능 개선을 얻는다. 가변성과 다형성 제약 외에 우리가 보통 클래스에서 기대하는 대부분의 사항이 그대로 적용되며 이러한 클래스는 제네릭 코드에 완전히 참가할 수 있다(예를 들어 object[] 또는 ArrayList<T>). 값 클래스의 기본값은 null이다.
 
primitive class 구문은 전통적인 객체에서 전통적인 프리미티브로 한 걸음 더 나아가는 클래스를 생성한다. 이러한 클래스의 기본값은 필드의 기반 값(int는 0, double은 0.0 등)으로 설정되며 null이 될 수 없다. 프리미티브 클래스는 최적화에서 가장 많이 얻고 기능 측면에서 가장 많이 희생한다. 프리미티브 클래스는 32비트 티어(tear) 안전성이 없다. 프리미티브 클래스는 궁극적으로 플랫폼의 모든 프리미티브를 모델링하는 데 사용되는데, 이는 사용자 및 라이브러리 정의 프리미티브 추가가 내장 요소와 동일한 시스템에 참여하게 된다는 것을 의미한다.
 

IdentityObject와 ValueObject

IdentityObject와 ValueObject는 프로젝트 발할라에 도입되는 두 개의 새로운 인터페이스다. 다루는 클래스의 종류를 런타임에 판단할 수 있게 해준다.
 
숙련된 자바 개발자 관점에서 가장 급진적인 구문 변화는 .ref 멤버의 추가일 것이다. 모든 형식에 이제 V.ref() 필드가 있다. 이 필드는 프리미티브의 박스처럼 동작하므로 int.ref는 Integer로 int를 래핑하는 것과 비슷하다. 일반 클래스는 .ref를 자신의 참조로 해석한다. 이것이 전체적으로 미치는 영향은 종류에 관계없이 변수에 대한 참조를 요청하는 일관적인 방법을 만든다는 것이다. 또한 모든 자바 배열이 “공변성을 갖도록(covariant)” 하는 효과도 있다. 즉, 모두 Object[]로부터 내려오는 자손이다. 따라서 이제 int[]는 Object[]의 자손이며 호출되는 모든 곳에서 사용 가능하다.
 

결론

값 클래스와 프리미티브 클래스는 자바와 그 생태계에 큰 영향을 미칠 것이다. 현재 로드맵은 값 클래스를 먼저 채택하고 이후 프리미티브 클래스가 도입되는 것이다. 다음은 새 프리미티브 클래스를 사용하기 위한 기존 프리미티브 박스 클래스(Integer 등)의 마이그레이션이다. 이러한 기능이 구현되면 다음 기능인 범용 제네릭(universal generics)은 프리미티브 클래스를 제네릭과 함께 바로 사용할 수 있도록 해서 API 재사용에 따르는 많은 복잡성을 완화하게 된다. 마지막으로, 특수 제네릭(T extends Foo의 모든 표현 기능을 허용)이 프리미티브 클래스와 통합된다.
 
프로젝트 발할라와 이를 구성하는 여러 프로젝트는 아직 설계 단계에 있지만 목표에 근접해지고 있으며 프로젝트를 중심으로 한 활동을 감안하면 값 클래스가 JDK 프리뷰에 적용될 시점도 멀지 않은 것으로 보인다.
 
이 같은 모든 흥미로운 기술적 작업 뒤에는 자바의 지속적인 생명력이 있다. 플랫폼을 근본적으로 발전시킬 수 있는 부분을 파악하기 위한 프로세스를 수행할 의지와 역량이 있다는 것은 곧 자바의 관련성을 유지하고자 하는 진실된 노력이 있다는 증거다. 프로젝트 룸(Loom)은 자바의 미래에 대한 낙관적 시각에 힘을 싣는 또 다른 과업이다.
editor@itworld.co.kr