자바 밸류 오브젝트(JEP 401), OpenJDK 마스터에 병합되다

오랫동안 프로젝트 발할라(Project Valhalla)라는 이름으로 진행돼 온 자바의 밸류 오브젝트 작업이 실제 코드로 한 걸음을 내디뎠다. OpenJDK의 PR #31120이 마스터 브랜치에 병합되면서 'JEP 401: Value Objects(Preview)'의 첫 프리뷰 구현이 본류에 들어온 것이다. 이 변경에는 밸류 오브젝트만이 아니라 'JEP 539: Strict Field Initialization in the JVM(Preview)'의 JVM 구현도 함께 포함됐다. 두 작업이 하나의 코드베이스에서 진행된 이유는 명확하다. JEP 401이 엄격한 필드 초기화에 의존하기 때문이다.

밸류 오브젝트가 무엇을 바꾸려 하는가

기존 자바에서 모든 객체는 고유한 식별성(identity)을 가진다. 두 객체의 필드 값이 같아도 == 비교나 동기화, 참조 기반 동작에서는 서로 다른 존재로 취급된다. 이 식별성은 유연함을 주지만, 런타임이 객체를 메모리에 배치하고 최적화하는 방식에는 제약이 된다. 밸류 오브젝트는 이 식별성을 포기한 객체다. 값 그 자체로만 의미를 갖는 데이터를 클래스 문법의 편의를 유지한 채 다루되, JVM이 내부적으로 더 자유롭게 표현하고 최적화할 여지를 열어 주려는 시도다. 이번 병합은 그 방향을 언어와 런타임에 실제로 심어 넣는 첫 프리뷰라는 점에서 의미가 있다.

JEP 539의 엄격한 필드 초기화가 전제 조건으로 함께 들어온 것도 이 맥락에서 이해할 수 있다. 식별성이 없고 값으로만 존재하는 객체는 생성이 완료되는 시점에 모든 상태가 확정돼 있어야 안전하게 다룰 수 있다. 필드가 반쯤 초기화된 상태가 노출되면 값 기반 표현의 전제가 무너지기 때문에, 생성자에서 필드 초기화 규칙을 더 엄격하게 강제하는 JVM 차원의 기반 작업이 함께 필요했던 것이다.

컴파일러·JVM·표준 라이브러리를 한꺼번에 건드리는 변경

이 작업의 규모는 병합 과정 자체에서도 드러난다. 변경은 언어 컴파일러, JVM(HotSpot), 표준 라이브러리에 걸쳐 서로 얽혀 있어 한 영역만 떼어내 리뷰하기 어렵다. 그래서 개발자들은 '마스터 풀 리퀘스트' 하나에 전체 코드 변경을 담아 두고, 영역별 논의는 동일한 코드 세트를 담은 여러 '서브 리뷰 풀 리퀘스트'로 나눠 진행하는 방식을 택했다. 최종 사인오프와 통합은 마스터 PR에서 기록되고, 서브 리뷰 PR들은 통합 없이 닫힌다. 관련 이슈로는 'JVM implementation of value classes and objects'(8317278)와 'Standard library implementation'(8317279)이 함께 묶였다.

실제 코드의 최신 상태는 별도의 valhalla/lworld 브랜치에서 유지된다. 이 브랜치는 주간 jdk 태그가 만들어질 때마다 jdk/master로부터 갱신되고, 그 시점에 마스터 PR과 모든 서브 리뷰 PR로 변경이 전파된다. 표면적이 넓은 만큼 jdk/master와 자주 충돌이 나므로, 리뷰어들은 최신 상태를 볼 때 valhalla/lworld를 참조하되 그것이 며칠 뒤처질 수 있다는 점을 함께 감안해야 한다. 대형 기능이 본류 개발 속도를 방해하지 않으면서 어떻게 병렬로 관리되는지 보여 주는 사례다.

커밋에 이르기까지

병합 절차 역시 OpenJDK의 협업 구조를 그대로 보여 준다. 이 변경을 올린 기여자는 프로젝트의 커미터(Committer) 자격이 없어, 기존 커미터가 스폰서로 나서야 통합이 가능했다. 자동 사전 통합 검사를 모두 통과한 뒤 변경을 '통합 준비' 상태로 표시하고, 스폰서가 이를 확인하는 과정을 거쳐 최종적으로 커밋 cc278db로 마스터에 반영됐다. hotspot 관련 변경이라는 이유로 최소 2건의 리뷰가 요구됐고, 리스트에 오른 리뷰어만 십수 명에 이른다.

실무자가 지금 알아 둘 것

중요한 것은 이것이 어디까지나 프리뷰라는 점이다. 프리뷰 기능은 정식 스펙이 확정되기 전 피드백을 받기 위한 단계로, 활성화하려면 별도의 프리뷰 옵션을 켜야 하고 이후 릴리스에서 문법이나 동작이 바뀔 수 있다. 따라서 지금 시점에서 밸류 오브젝트를 운영 코드에 도입하는 것은 적절하지 않으며, 실험과 검증의 대상으로 접근하는 편이 맞다. 반대로 성능에 민감한 데이터 구조를 다루거나 값 중심 도메인 모델을 설계하는 팀이라면, 향후 표준화될 이 모델이 자신들의 코드와 라이브러리에 어떤 영향을 줄지 미리 가늠해 둘 만하다.

마스터 병합은 밸류 오브젝트가 '연구 브랜치의 아이디어'에서 '본류에서 함께 다듬어질 후보'로 자리를 옮겼다는 신호다. 다만 이번 자료만으로는 정식 정착 시점이나 구체적인 성능 이점을 단정할 수 없다. 여러 서브 리뷰가 마무리되고 후속 프리뷰가 이어지는 과정을 지켜보는 것이 지금으로선 가장 현실적인 태도다.