답변:
이에 대한 자세한 내용은 OpenJDK 페이지에서 설명합니다. JDK 7 프로젝트 업데이트 제안 Q & A
이 프로젝트는 Oracle JDK 7 업데이트 릴리스의 기반이됩니까?
예.
OpenJDK 6에 대한 Joe Darcy의 FOSDEM 블로그 게시물에서 인용하려면 :
특히, OpenJDK 6과 6 업데이트 트레인 사이에있는 것과 같이 OpenJDK 7 코드베이스와 7 업데이트 코드베이스 사이에는 이분법이 없습니다.
필자가 읽은 바에 따르면 본질적으로 패치와 업데이트는 일반적으로 먼저 Open JDK로 이동 한 다음 가능한 한 짧은 지연 시간으로 Oracle JDK로 제공됩니다.
보안 패치의 경우 그림이 반대 인 것처럼 보입니다. 즉, 먼저 Oracle 릴리스로 이동 한 다음 OpenJDK로 (가능한 한 작은 지연 시간으로) 기대합니다.
7 업데이트 프로젝트는 Oracle의 보안 수정 사항을 받습니까?
예.
OpenJDK 6과 마찬가지로, 보안 수정 사항은 영향을받는 JDK 릴리스 트레인에 대한 수정 사항의 일반 동기화 된 공개의 일부로 공개 포리스트로 푸시되기 전에 먼저 기밀로 유지되고 개인 포리스트에 적용됩니다. 또한 공개 코드 검토 및 취소 승인 프로세스를 거치지 않으며 프로젝트 이슈 트래커의 해당 이슈는 공개적으로 표시되지 않습니다.
이 프로젝트는 언제 오라클로부터 보안 픽스를 받습니까?
Oracle Java SE Critical Patch Updates 일정은 공개되어 있습니다 .
이 프로젝트의 소스 코드에 대한 보안 픽스는 JDK 7 업데이트 프로젝트에서 Oracle 제품과 동일한 시점에 제공 될 예정입니다 ...
Oracle과 Open JDK를 동기화하는 데 많은 노력이 필요한 이유를 더 잘 이해하려면 이전 프로젝트에 대한 Oracle 결정을 살펴 보는 것이 좋습니다 . 공식 Java SE 7 참조 구현으로 OpenJDK로 이동 :
... Oracle 및 Java SE 7 Expert Group의 다른 구성원은 Java SE 7 사양 ( JSR 336 ) 을 마무리했습니다 . 스펙 리더로서의 역할에서 Oracle은 Java SE 7 Reference Implementation을 제공 할 책임이 있습니다. 우리는 OpenJDK 오픈 소스 코드를 전적으로 기반 으로하고 GPL 오픈 소스 라이센스에 따라 사용 가능한 Reference Implementation을 제공 할 것입니다. .
참조 구현 (RI)의 역할은 모든 Java 구현에 대한 표준으로 사용됩니다. Java SE 호환으로 인증 된 구현을 구현하려면 구현자는 많은 호환성 테스트 (TCK)를 통과해야합니다. 또한, 구현은 호환성의 추가 점검으로 RI와 비교 될 수 있습니다. 기본적으로 구현이 RI와 동일한 동작을 갖도록 인증 된 경우 Java와 호환됩니다. 이 주제에 대한 자세한 정보는 JCP FAQ를 참조하십시오 .
역사적으로 Sun은 항상 Sun JDK를 RI로 사용했으며 BCL (Binary Code License)에 따라 사용할 수있었습니다. 이는 제품 구현이 정의에 따라 호환 가능하다는 것을 의미했기 때문에 Sun에게는 매우 편리했습니다. 그러나 Sun JDK에는 Java 플러그인과 같이 표준에 포함되지 않은 기능이 상당히 많이 포함되어있어 혼란 스러웠습니다. 또한이 관행을 계속 유지하면 오픈 소스 구현자가 공식 RI 소스 코드를 연구하고 평가할 수 없기 때문에 문제가 발생합니다. (Oracle JDK의 소스 코드는 OpenJDK와 약간 다릅니다. 앞으로 해결할 문제가 있습니다).
이를 염두에두고 Oracle은 다음을 수행합니다.
위의 결정은 공식적으로 확인, 테스트, 라이센스 및 호환 코드를 공개하기 위해 Open JDK 코드를 작성하기위한 많은 노력을 의미합니다. 합의 된 공개 일정에 따라 릴리스해야한다고 덧붙였다면, 그러한 노력은 이전의 "전통적인"Sun / Oracle Java 릴리스에했던 것과 거의 같을 것입니다.
따라서 Open 및 Oracle JDK 코드 기반을 최대한 가깝게 유지하는 것이 합리적입니다. 그렇지 않으면 TCK를 준수하는 두 프로젝트를 개발하기위한 개발 및 수정의 중복이 엄청나게 어려워 질 수 있습니다.
Open JDK를 참조 구현으로 사용하기로 한 결정은 Oracle이 JDK 7의 출시까지 Open JDK와 최대한 동기화되도록 JDK를 최대한 유지하기 위해 Oracle이 가장 큰 관심을 갖도록 한 결정입니다.
JDK 7 업데이트 릴리스를 통해 오라클이 동기를 유지하도록 동기를 부여 할 수있는 사항을 이해하려면 Open JDK 8 프로젝트를 살펴 보는 것이 좋습니다 .이 목적은 Open JDK 7과 매우 유사합니다.
이 프로젝트의 목표 는 Java Community Process 에서 JSR 337 에 의해 정의 된 Java SE 8 플랫폼의 오픈 소스 참조 구현을 생성하는 것입니다 .
JDK 7의 참조 구현과 관련하여 위에서 설명한 것과 동일한 추론을 위해, Oracle은 JDK의 업데이트를 가능한 한 동기화 된 상태로 유지하는 것이 가장 큰 이익입니다.
이러한 JDK간에 더 많은 차이점이있을수록 TCK를 준수하기 위해 자체 릴리스를 가져 오는 데 필요한 노력이 중복되어 Oracle이 Java SE 8을 릴리스하기가 더 어려워집니다. 반대의 경우도 마찬가지입니다. 즉, 두 프로젝트가 모두 가까워 질수록 Java 8 구현을 모두 릴리스하는 데 더 적은 노력이 필요합니다.
다른 클라이언트를 대상으로 동일한 소프트웨어의 두 가지 약간 다른 버전을 병렬로 지원 한 적이 있습니까? 그렇다면 가능한 한 가깝게 유지하려는 바람과 동기화되지 않았을 때 겪게되는 불편 함을 모두 기억할 것입니다. Open 및 Oracle JDK를 사용하면 규모가 훨씬 커집니다.
거의 모든 버그 수정은 OpenJDK 프로젝트를 통해 직접 다운 스트림 JVM 공급 업체 (Oracle, Azul, RedHat 등)로 전달됩니다.
예외적으로 일부 보안 패치는 다시 OpenJDK로 다시 포팅되기 전에 다운 스트림 버전 (특히 Oracle)에서 수정됩니다. 이를 통해 공급 업체는 오픈 소스 프로젝트의 취약성을 공개하기 전에 보안 수정 프로그램으로 전세계 대부분을 업그레이드 할 수 있습니다.
일부 공급 업체는 변경 사항을 다시 OpenJDK로 푸시하지 않기로 선택합니다. 예를 들어 Google과 Twitter는 내부에서 사용하는 OpenJDK 버전을 버그 수정 및 기본 OpenJDK 프로젝트로 돌아 가지 않은 기능으로 수정했습니다.
HTH