자바 9 기능

Oracle은 Java 9의 첫 번째 개선 계획 세트(JEP라고 함)가 2016년 초에 출시될 것으로 확인되었다고 발표했습니다.

세 가지 새로운 API가 발표되었습니다.

업데이트 후 Process API는 운영 체제에서 JAVA 이외의 관련 프로세스와 상호 작용할 수 있습니다. 현재 사용되는 API에는 많은 제한 사항이 있어 개발자가 이를 강요합니다. 자주 네이티브 코드로 전환합니다. 이 API의 주요 위험은 운영 체제, 특히 Windows의 이기종 특성입니다. API 설계는 다양한 운영 체제의 소형 장치 배포에 맞게 조정되어야 하며, 동일한 운영 체제 프로세스에서 여러 Java 가상 머신이 실행되는 환경도 고려해야 합니다. 이러한 고려 사항은 보다 추상적인 API로 이어져 설계 작업 부하를 증가시킵니다.

HTTP/2에 대한 지원을 도입하는 새로운 HTTP 클라이언트.

기존 API의 문제점 및 구현:

URLConnection 기반 API는 여러 프로토콜을 염두에 두고 설계되었으며 그 중 많은 프로토콜이 폐기되었습니다(ftp, gopher 등)

이전 HTTP 1.1은 너무 추상적이었습니다.

사용하기 어려웠습니다(많은 동작이 문서화되지 않았습니다)

차단 모드에서만 작동했습니다(요청/응답당 하나의 스레드)

매우 어려웠습니다. 유지하기 위해

Https 2.0 지원은 현재 JDK에서 지원되지 않는 TLS ALPN(Application Layer Negotiation Extension)에 의존합니다. HTTP 2.0 사양 자체는 아직 인터넷 초안 형태이지만 예상됩니다. 2014년에 제공될 예정입니다. 공식 초안이 됩니다.

새로운 경량 JSON API: JSON 문서 및 데이터 스트림을 처리하고 생성하기 위한 경량 API를 제공합니다. 후자는 표준화된 JSON 지원을 기반으로 하며 JSR 353의 일부입니다.

또한 세 가지 JVM 및 성능 관련 기능이 발표되었습니다.

스레드가 객체에 액세스하기 위해 경쟁할 때 성능을 향상시키도록 설계된 향상된 경합 잠금입니다. 경합 잠금을 개선하면 특히 Volano 및 DaCapo와 같은 산업 벤치마크에 대한 실제 애플리케이션에 큰 이점이 될 것입니다.

이 프로젝트에서는 경쟁 Java 모니터와 관련된 다음 영역의 성능 개선을 탐구합니다.

필드 재정렬 및 ​​캐시 라인 정렬

Accelerate PlatformEvent::unpark()

빠른 Java 모니터 입력 작업

빠른 Java 모니터 종료 작업

빠른 Java 모니터 알림/notifyAll 작업

및 SPARC의 SpinPause

에 대한 적응형 스핀 개선

JIT 컴파일러의 코드 캐시를 분할합니다(대규모 애플리케이션에서 더 나은 JIT 성능을 위해). 코드 캐시를 각각 특정 형식의 컴파일된 코드를 포함하는 독립된 세그먼트로 나누는 것은 성능을 향상하고 향후 확장을 지원하기 위한 것입니다.

컴파일된 코드의 구성 및 유지 관리는 성능에 큰 영향을 미칩니다. 코드 캐시가 잘못된 방향으로 진행되면 여러 가지 성능 저하 사례가 알려지게 됩니다. 다단계 컴파일이 도입된 후에는 코드 캐싱 상태가 매우 중요해집니다. 왜냐하면 컴파일된 코드의 양이 다단계 컴파일을 사용하지 않는 경우에 비해 2~4배 증가하기 때문입니다. 다중 레벨 컴파일에는 계측된 컴파일 코드(격리된 코드)라는 새로운 유형의 컴파일 코드도 도입되었습니다. 외계인 코드는 프로파일되지 않은 코드와 다른 속성을 가지고 있습니다. 한 가지 중요한 차이점은 프로파일링된 코드에는 항상 코드 캐시에 남아 있는 프로파일링되지 않은 코드와 달리 미리 정의된 제한된 수명 주기가 있다는 것입니다.

기존 코드 캐시는 단일 코드에 최적화되어 있습니다. 즉, 한 가지 형태의 컴파일된 코드만 있습니다. 코드 캐시는 인접한 메모리 블록의 헤드에 위치한 별도의 힙 데이터 구조로 구성됩니다. 결과적으로 사전 정의된 제한적인 수명을 가진 프로파일링된 코드는 프로파일링되지 않은 코드와 혼합되어 코드 캐시에 영구적으로 남아 있게 되며, 이로 인해 다양한 성능 및 디자인 문제가 발생합니다. 예를 들어, 스위퍼 메소드는 스캔할 때 코드 캐시의 일부 엔터티가 업데이트되지 않거나 메소드 코드가 아닌 경우에도 전체 코드 캐시를 스캔하도록 강제됩니다.

여러 기능 중에서 병렬 및 공유 컴파일을 지원하는 sjavac이라는 "스마트" Java 컴파일러의 심층 개발입니다.

다양한 안정성 및 이식성 문제로 인해 sjavac은 기본적으로 JDK 빌드 스크립트에서 사용되지 않습니다. 이 JEP의 첫 번째 목표는 이러한 문제를 해결하는 것입니다. 여기에는 필요한 도구가 모든 하드웨어에서 일관되게 안정적인 결과를 생성하는지 확인하는 것이 포함됩니다. 그리고 소프트웨어 구성.

전반적인 목표는 sjavac의 품질을 향상시켜 다양한 대규모 Java 프로젝트를 컴파일할 수 있는 범용 javac 패키지로 만드는 것입니다.

후속 프로젝트에서는 가능하다면 JDK 도구 체인에서 sjavac을 분리하는 방법을 계속해서 탐구할 것입니다. sjavac은 독립형 지원 도구, javac와 통합된 비독립형 도구 등이 될 수 있습니다.

마지막으로 JEP 201에서는 매력적인 기능인 모듈식 소스 코드가 약속되었습니다. 이것은 실제로 우리가 모듈식 솔루션 "Project Jigsaw"(원래 Java 8의 일부로 대상)로 알고 있던 것입니다.

Jigsaw 프로젝트는 Java SE 플랫폼에 맞게 표준화된 모듈 시스템을 설계 및 구현하고, 이를 자체 플랫폼에 적용한 후 JDK에 투자하는 것을 목표로 합니다. 초기 목표는 플랫폼 구현을 소형 장치로 더 쉽게 확장하고, 보안 및 유지 관리성을 개선하고, 애플리케이션 성능을 개선하고, 대규모 애플리케이션에 직면했을 때 개발자에게 더 나은 도구를 제공하는 것입니다.

이번 JEP는 Jigsaw 프로젝트의 첫 번째 단계의 일부입니다. 다음으로 JEP는 JRE 및 JDK 이미지를 모듈화한 후 모듈 시스템을 도입합니다.

초기 단계에서 소스 코드를 재구성하는 동기는 다음과 같습니다.

JDK 개발자에게 시스템의 모듈식 구조에 익숙해질 수 있는 기회를 제공합니다.

모듈 시스템이 도입되기 전에도 빌드에 모듈 경계를 적용하여 구조를 계속 발전시킵니다.

기존의 비모듈식 코드를 모듈식 코드로 항상 "천천히" 변환하는 대신 Jigsaw 프로젝트를 심층적으로 개발합니다.