JEP 401 Value Objects (Preview)가 OpenJDK master에 병합되었습니다
개요
JEP 401 Value Objects (Preview)와 JEP 539 Strict Field Initialization이 OpenJDK master 브랜치에 병합되었습니다.
Pull request #31120은 2,934개의 커밋을 통합하며 208,011개의 추가 사항과 13,161개의 삭제 사항을 포함하였고, JEP 539와 함께 JEP 401의 첫 번째 프리뷰를 구현했습니다. 이 변경 사항은 병합 충돌을 해결하고 필요한 승인을 받은 후 2026년 7월 31일에 통합 준비가 완료되었습니다. 모든 결과 코드는 jdk/master와 매주 태그로 동기화되는 valhalla/lworld 저장소에서 추가로 개발되어야 합니다.
언어 구현
Java 언어는 이제 불변이며 identity(식별성)가 없는 타입을 정의하는 value class 선언을 허용합니다.
이 변경 사항은 sub‑review JDK-8317277 (Java language implementation of value objects)에 해당합니다. Value classes는 List<T> 및 Comparable<T>와 같은 제네릭 타입의 타입 인자로 사용될 수 있습니다. 한 댓글 작성자가 언급했듯이, "List
JVM 구현
JVM은 전통적인 object header 없이 value objects를 할당하고, JEP 539에서 프리뷰된 대로 엄격한 필드 초기화를 강제하도록 업데이트되었습니다. 이 작업은 sub‑review JDK-8317278 (JVM implementation of value objects)에서 추적됩니다. JVM은 이제 value objects를 inline types로 취급하여 object identity와 관련 헤더 오버헤드를 제거합니다. 한 논평가는 다음과 같은 의문을 제기했습니다: "제가 제대로 이해했다면 Integer는 value class가 되고 모든 인스턴스가 object identity를 잃게 됩니다. 세부 사항에 대한 지식은 많지 않지만, 시작부터 꽤 대담한 움직임처럼 보입니다." 다른 이는 데이터 제한에 대해 물었습니다: "최신 상태는 어떤가요? 여전히 63비트 데이터에 null 허용을 위한 1비트가 추가된 형태인가요?" 이러한 질문들은 이 기능의 프리뷰 성격을 반영합니다.
표준 라이브러리 업데이트
코어 라이브러리 조정은 String과 같은 기존 참조 타입을 유지하면서 value objects를 수용합니다. sub‑review JDK-8317279 (Standard library implementation of value objects)는 value types와 함께 작동하도록 JDK를 업데이트했습니다. 한 커뮤니티 멤버는 다음과 같은 남은 차이점을 관찰했습니다: "정말 멋지네요, String이 불변임에도 불구하고 Integer처럼 완전히 구별 불가능해질 수 없다는 점이 아쉽습니다." 한편, 다른 이는 다음과 같이 발전을 찬양했습니다: "현대적인 Java는 정말 끝내줍니다. 요즘 왜 OG(Original) 말고 다른 걸 써야 하는지 정말 이해할 수가 없네요!"
JEP 539와의 관계
JEP 401은 value object 필드가 사용 전에 완전히 초기화됨을 보장하기 위해 JEP 539의 엄격한 필드 초기화 프리뷰에 의존합니다. Pull request 설명에는 JEP 401이 엄격한 필드 초기화에 의존하기 때문에 JEP 539가 동일한 코드 베이스에 구현되었다고 명시되어 있습니다. 이 의존성에 대한 추가적인 언급은 소스 자료에 나타나지 않습니다.
커뮤니티 반응
Hacker News 댓글 작성자들은 이 병합을 성능의 이정표로 환영하며, 그 범위와 더 넓은 Valhalla 노력과의 관계에 대해 논의했습니다.
저는 이 부분에서 외로움을 느낍니다. 저는 주로 언어로서의 Java를 사랑합니다. value types의 부재는 특정 유형의 성능에 있어 가장 큰 장애물입니다. 저는 이 언어의 진화를 정말 기대하고 있습니다. – @timmg 이것이 무엇을 다루고 무엇을 다루지 않는지 이해하는 것이 중요하다고 생각합니다. 이것은 "Valhalla의 첫 번째 부분일 뿐입니다". 예를 들어 https://www.jvm-weekly.com/p/project-valhalla-explained-how-... 에 있는 좋은 요약을 참조하세요. – @mormegil Java 리드들이 언어를 발전시키면서도 가능한 한 하위 호환성을 유지하기 위해 얼마나 많은 생각과 노력을 기울여 변화를 출시하는지 항상 놀랍습니다. – @ludovicianul 현대적인 Java는 정말 끝내줍니다. 요즘 왜 OG 말고 다른 걸 써야 하는지 정말 이해할 수가 없네요! – @exabrial 마침내 여기서 움직임이 보이는 것을 보니 정말 좋네요. value types의 부재는 수십 년 동안 Java에서 가장 큰 성능 함정 중 하나였습니다. – @swiftcoder 두 언어 모두 여전히 새로운 기능을 받고 있지만, Java가 JavaScript보다 앞서 나가는 것처럼 보여서 흥미롭습니다: - Java는 Date에 대한 현대적인 대체제를 오래전부터 가져왔지만, JavaScript의 최근 표준화된 Temporal API는 여전히 Safari에서 지원되지 않습니다. - Java에는 switch expressions가 있지만, JavaScript는 Scheme의 영향을 받았음에도 불구하고 그렇지 않습니다. - 그리고 이제 Java는 value objects를 얻고 있지만, JavaScript의 대응되는 tuples & records 제안은 철회되었습니다. – @sheept List
및 Comparable 와 같은 제네릭 타입은 value classes를 타입 인자로 하여 인스턴스화될 수 있습니다. JEP 218, Generics over Primitive Types (with revisions)는 제네릭 클래스와 메서드가 value class 타입으로 매개변수화될 때 필드, 배열 및 로컬 변수 레이아웃을 특수화할 수 있도록 허용할 것입니다. 와, 이거 정말 멋지네요! JVM은 더 나은 메모리 할당 및 최적화를 위해 컴파일 타임에 알려진 값 크기를 사용할 수 있는 더 많은 방법이 필요합니다. – @ivanjermakov 제가 제대로 이해했다면 Integer는 value class가 되고 모든 인스턴스가 object identity를 잃게 됩니다. 세부 사항에 대한 지식은 많지 않지만, 시작부터 꽤 대담한 움직임처럼 보입니다. – @weinzierl Project Valhalla에 대한 이전 HN 토론: https://news.ycombinator.com/item?id=48595511 – @kuhsaft 이 설계의 이유를 자꾸 잊어버리게 되네요 - 왜 value semantics가 사용 시점(use site)이 아니라 선언 시점(declaration site)에 내장되어 있나요? 왜 클래스 작성자가 이를 value type으로 선언해야 하나요? Brian이 이전에 여러 번 다시 다루었다는 것을 알지만 자꾸 이유를 잊어버리게 됩니다. – @swaranga 특수화된 제네릭이 여전히 부족함에도 불구하고 정말 좋네요. 이러한 개선 사항은 Scala에 특히 유익할 것이라고 생각합니다. Scala는 매우 강력한 언어이지만, JVM에서 추상화하는 것은 큰 대가가 따르기 때문입니다. – @pregnenolone 2934개의 커밋이라니 세상에... 엄청난 작업이네요. – @germandiago 정말 멋지네요, String이 불변임에도 불구하고 Integer처럼 완전히 구별 불가능해질 수 없다는 점이 아쉽습니다. – @parallax_error 최신 상태는 어떤가요? 여전히 63비트 데이터에 null 허용을 위한 1비트가 추가된 형태인가요? – @HexDecOctBin MR이 닫혔습니다. 바로 이것입니다 https://github.com/openjdk/jdk/commit/cc278dbb8a1ca0754d5842... – @ligarota 이것이 Valhalla의 얼마나 되는 부분인가요? 50%인가요? 90%인가요? – @whytevuhuni 나중에 보려고 북마크함 – @hn4yci687u