JDK 9이 JDK 8에서 초기화 되면 릴리즈 간의 코드라인 병합은 중단 될 예정.
개발자들과 함께 JDK 8에서 JDK 9으로 JDK 구축의 이행을 준비중인 오라클의 자바 최고 책임자는 두 JDK간의 코드라인의 병합을 제한 할 것을 제안하였다.
오라클 자바 플랫폼 그룹의 치프 아키텍트인 Mark Reinhold는 OpenJDK 메일 링 리스트에서 JDK 8으로의 변경 내역은 줄어드는 반면 JDK 9의 포레스트(참고: OpenJDK Mercurial Forest)는 조만간 오픈 될 것 이며 개발자들은 이제 두 개의 개별 릴리즈에 대한 변경 내역들을 각각 관리 해야 한다는 것 을 언급 하였다.
현재의 일반적인 규칙은 변경 내역 들이 개발 중인 릴리즈에 먼저 이행 되고 앞선 릴리즈에 백 포트 되는 것 이다. 하지만 새롭게 시작하는 후속 릴리즈(지금의 경우 JDK 9)에서 보다 기능 릴리즈의 최종단계인 릴리즈 준비단계 이후(지금의 경우 JDK 8)의 주기에서 변경사항 들이 좀더 충분히 테스트 될 수 있을 것이기 때문에 이러한 규칙은 크게 의미가 없게 된다. 이는 후속 릴리즈에 변경 내역들이 먼저 전달 됨으로 인해 최종 릴리즈 단계의 작업이 지연되는 것을 의미한다.
JDK 7까지는 이러한 두 버전간의 평행선상의 변경 내역을 처리하기 위한 정책이 없었다. 개발자는 일반적으로 먼저 요청 된 릴리즈를 대상으로 변경 내역을 적용하는 반면 썬/오라클의 릴리즈 엔지니어링 팀의 누군가는 최종 버전과 후속 릴리즈 사이의 반자동 병합을 수행 하며 이러한 병합 작업은 더 이상 병합이 불가능 하게 되는 시점까지 수행되었다. 그렇게 되면 개발자는 이러한 변경 내역들이 정확하게 해당하는 릴리즈에 반영되는 것을 보장하는데 도움을 주는 버그 데이터베이스 쿼리를 이용하여 두 릴리즈 모두에 변경 내역을 적용하는 것을 요청하게 되어 있었다.
Reinhold는 이러한 접근 방식은 최종 릴리즈에 기여하는 수백명의 개발자들 모두가 반자동 병합 작업 들이 아직 수행 중에 있는지 모니터링 해야만 하고 병합 작업이 중단 된 즉시 자신들의 코드 통합과 관련한 작업 절차들을 변경해야 하기 때문에 작업들을 효율적으로 조율하기가 어렵다고 이야기 하고 있다.
이러한 최총 릴리즈 절차를 단순화 하기 위해 Reinhold는 JDK 9의 개발 포레스트는 JDK 8의 특정 빌드로부터 초기화 할 것을 제안 하였다. 이 특정 빌드의 JDK 8에서 JDK 9이 분기 된 이후에는 두 릴리즈 간의 코드 라인 병합은 허용되지 않을 것 이며 JDK 8에 변경 내역을 반영한 개발자는 해당 변경 내역이 JDK 9에도 적용 가능한 경우 JDK 9에도 개별적으로 적용 시켜야 한다.
Reinhold는 이러한 변화로 인해 기존 프로세스의 문제가 해결되길 원하고 있다. 유일한 단점으로 보이는 것은 GA(General Availability)이전의 JDK 8으로부터 분기된 JDK 9의 포레스트를 이용해서는 JDK 8 GA의 빌드가 불가능해 진다는 것이다. 기술적인 관점에서 이를 가능하게 하는 것은 다소 편리하면서도 멋진 일이겠지만 이러한 변화는 미학적인 면을 좀더 고려한 것 임을 밝혔다. 한편 JDK 8 포레스트를 통해 JDK 7 업데이트 릴리즈를 빌드 할 수 없다는 점에서 본다면 이 문제와 관련하여 상황이 달라지는 것은 아니다.
Java SE 8 기반의 환경에서 멀티코어 프로세서에서 동작하는 코드의 작성을 손쉽게 하기 위한 람다 프로젝트를 지원할 JDK 8은 해당 체험판 빌드가 이미 존재하는 상태이다. 한편 2016년 초 등장 예정이며 Java의 모듈화 기능인 Jigsaw 프로젝트를 제공할 Java SE 9의 릴리즈에 착수한 상태이다.
