9월 21일 Java 9 출시됩니다.

from: https://www.infoq.com/news/2017/09/Java-9-release-sept-21

자바 SE의 차기 릴리스인 버전 9는 2017년 9월 21일에 릴리스 될 예정이며 일부 주요 변경 사항이 있습니다.

JDK 9의 핵심 변화는 오라클에 따르면 "새로운 종류의 Java 프로그래밍 구성 요소인 모듈, 명명된 자체 코드 및 데이터 모음"을 소개 한 것입니다. 모듈 기술의 핵심 목표는 Java 응용 프로그램과 핵심 Java 런타임 자체의 크기와 복잡성을 줄이는 것입니다. 이를 위해 JDK 자체가 모듈화되어 오라클이 성능, 보안 및 유지 보수성을 개선하고자 합니다.

Java 9 모듈을 지원하기 위해 루트 디렉토리에 module-info.class 파일이 있는 새로운 모듈형 JAR 파일도 도입되었습니다. 오라클은 전체 Java 런타임을 요구하지 않고 모듈 세트를 사용자 정의 런타임 이미지로 어셈블 및 최적화 할 수 있는 도구를 도입했습니다. 모듈화의 결과로 인한 기타 변경 사항에는 Java 런타임 이미지에서 rt.jar 및 tools.jar을 제거하는 것이 포함됩니다.

InfoQ는 Java Community Process (JCP) 집행위원회 멤버인 Ben Evans 에게 Java 9.0의 모듈 시스템에 대한 생각을 전했다.

에반스 : 리팩토링을 가장 필요로 하는 애플리케이션이 모듈화를 위한 최상의 목표일 수 있다고 생각합니다. 이미 Lava Flow / God Class / Stovepipe System 지옥에 있고 이해 관계자가 알고 있다면 리팩토링을 완전히 배제하고 완전히 모듈화된 솔루션으로 향하는 노력이 더 쉬울 수도 있습니다 (vs Java 8로의 리팩토링과 이전)만으로도 가치가 있습니다.

오라클은 Java 8이 2022년까지 지원되는 장기간 지원 릴리스일 것이라고 발표한 이후 Evans는 많은 애플리케이션이 Java 8에 머무르고 Java 9로는 전혀 업그레이드하지 않을 수도 있다고 생각합니다. 에반스는 일부 애플리케이션이 개발자를 떠나 버전 8에서 툴체인을 구축하고 프로덕션 환경에서 Java 9 런타임을 사용하기로 결정할 것이라고 덧붙였습니다.

이것은 특정 응용 프로그램에 대해 많은 의미를 가질 수 있습니다. 예를 들어 ~ 40G의 문자열 데이터를 포함하는 큰 힙을 가진 전자 상거래 사이트를 보았습니다. 자바 9의 컴팩트 스트링은 메모리 사용량을 절반으로 줄입니다. 이는 GC 성능에 긍정적인 영향을 미칩니다. 일부 응용 프로그램 (대용량 Solr 설치 또는 이와 유사한 응용 프로그램 포함)의 경우 단일 이점은 런타임시 9로 업그레이드하는 것이 좋습니다.

Java 9는 이전에 기본값이었던 Parallel GC 대신 G1을 기본 가비지 수집기로 사용합니다. Evans는 이 변경에 대해 다음과 같이 설명했습니다.

G1은 Parallel보다 애플리케이션 스레드에서 더 많은 작업을 수행하기 때문에 이 변경이 중요할 수 있습니다. 기본적으로 none은 아니지만 GC 스레드를 사용하여 거의 모든 메모리 관리 작업을 수행합니다. 즉, G1로 전환하면 응용 프로그램 스레드에 추가 작업이 추가되고 응용 프로그램의 성능에 직접 영향을 미칩니다.

대부분의 경우 (아마도 심지어 대부분)이 추가 성능 오버 헤드는 문제가 되지 않습니다. 그러나 이 분야에서 병렬 작업에서 G1 작업으로 이동할 때 작업 부하의 상당 부분이 성능 저하를 관찰할 수 있음을 확인했습니다. 이러한 애플리케이션의 경우 성능 저하가 용납될 수 없으므로 G1 수집기로 이동할 수 없습니다. G1이 기본값이 되면 이제 Java 9로 이동하는 모든 응용 프로그램에 영향을 미칠 수 있습니다.

InfoQ는 대규모 코드베이스가 모듈로 리팩토링하는 것이 바람직하다면 JClarity의 CEO이자 런던 자바 사용자 그룹의 공동 주최자 인 Martijn Verburg 에게 질문했다 .

Verburg : 그렇습니다. 그리고 다루고 있는 커다란 코드 베이스는 이미 OSGi, Maven 모듈, JBoss 모듈 또는 명백한 패키지와 인터페이스에 관한 자생적인 규칙 세트를 통한 것이든 간에 모듈 구조의 일부 유사점으로 이미 분할되었습니다.

Verburg는 좋은 모듈화 조언을 제공하며 개발자가 Java 9 모듈 시스템을 채택 할 때 조심해야 할 사항을 지적합니다.

• Paul과 Sander의 Java 9 모듈성에 대한 책을 읽으십시오 - 모든 연관성과 모듈, 패키지 및 JAR 사이의 관계가 어떻게 작동하는지에 대한 확실한 안내서입니다.
• 모듈 경계에서 인터페이스를 잘 정의하고 인터페이스에 코드를 작성하십시오.
• 분할 패키지가 없으므로 패키지가 두 개의 모듈로 분할되어서는 안됩니다. AdJET OpenJDK 프로그램의 Patrick Reinhart는 기존 코드에서 실행할 수 있는 탐지 도구 를 제공합니다.
• 주기적인 의존성이 없는지 확인하십시오 (Jigsaw는 허용되지 않습니다).
• 모듈이 소스에 배치되는 방식은 익숙한 방식과 다르게 보일 것입니다. 따라서 빌드 도구가 적절하게 대처할 수 있는지 확인하십시오.
• Jigsaw는 버전을 지원하지 않습니다.

Verburg에 따르면 핵심 요소는 주기적 종속성을 수정하고 패키지를 분할하고 인터페이스에 코드를 작성하는 것입니다. Jigsaw를 사용하여 모듈화를 시도하기 전에 기존 코드베이스에서 이 작업을 수행해야 합니다. 또한 모듈화 된 애플리케이션만 Java 9에서 실행될 수 있다는 소문에 대해서도 언급했습니다.

사람들이 Java 9에서 실행하기 위해 모듈화된 응용 프로그램이 있어야 한다고 실수로 말하는 사람들이 많이 있습니다. 이는 사실이 아니며 Java 9에서 기존 클래스패스 기반 응용 프로그램을 정상적으로 실행할 수 있습니다. 몇 가지 새로운 보안 제한 사항이 있습니다. 즉, 몇 가지 특수 런타임 플래그를 설정해야 할 수도 있습니다 (Java 내부에 액세스하는 새롭고 안전한 방법을 사용하도록 코드를 리팩토링 할 때까지). 하지만 기본 설정은 경고입니다. 실행 안되는 것 (Java 10은 더 강요할 것입니다)에 반대합니다.

Verburg는 Jigsaw가 Java가 더 빨리 움직일 수 있는 토대라고 생각합니다. Mark Reinhold, Alan Bateman, Mandy Chung과 그 밖의 Jigsaw 팀이 수년간 지칠 줄 모르는 노력으로 그 일을 해냈습니다.

Java 9는 또한 jshell 도구를 소개합니다. 이 명령 행 환경은 REPL (Read-Eval-Print-Loop) 형식을 Java 플랫폼에 제공합니다. 이는 코딩 옵션의 프로토 타이핑 및 탐색을 용이하게 하고 즉각적인 결과 및 피드백을 제공하기 위한 것입니다.

Verburg와 Evans는 모두 Java 9에서 jShell이 ​​포함 된 것을 보게 되어 매우 기뻐합니다. HTTP/2가 Java 9에서 인큐베이터 모듈로 출하된다는 실망감에 대해 언급하고 있지만, Evans는 오라클이 이 기능에 대한 상당한 관심과 지원을 제공함으로써 Oracle GA로 HTTP/2를 제공할 수 있는 충분한 엔지니어링 자원을 투입해야 한다고 생각합니다.

JDK 9의 변경 사항 전체 목록은 Oracle 웹 사이트 에서 찾을 수 있습니다. 6개월 릴리스 주기로 발표로 전환되는데, 자바 9의 출시는 지금까지 자바 오라클의 책임을 특징으로 한 "키스톤" 릴리스 스타일이 마지막임을 나타냅니다. Java의 진화의 다음 단계는 기능 지향적인 보다 짧은 릴리스에 의해 주도될 것으로 보입니다. 이것이 자바가 선도적인 서버 측 기술들 사이에서 입지를 유지할 수 있을지 여부는 아직 밝혀지지 않았습니다.