20 Jahre Erfahrung FreeCall 0800 tutegos

Neues in Java 9

Im März 2014 wurde Java 8 final und der Nachfolger ist Java 9. Der Zeitplan bis zum Release war:

2016-05-26 Feature Complete ✔
2016-12-22 Feature Extension Complete ✔
2017-01-05 Rampdown Start ✔
2017-02-09 All Tests Run ✔
2017-02-16 Zero Bug Bounce ✔
2017-03-16 Rampdown Phase 2 ✔
2017-07-06 Final Release Candidate ✔
2017-09-21 General Availability ✔

Der Nachfolger von Java 9 ist Java 10 (aka Java 18.3), was seit März 2018 verfügbar ist.

Die JEPs (JDK Enhancements) sind:

JEP 102: Process API Updates. Improve the API for controlling and managing operating-system processes.
JEP 110: HTTP/2 Client. Define a new HTTP client API that implements HTTP/2 and WebSocket, and can replace the legacy HttpURLConnection API.
JEP 143: Improve Contended Locking. Improve the performance of contended Java object monitors.
JEP 158: Unified JVM Logging. Introduce a common logging system for all components of the JVM.
JEP 165: Compiler Control. Improve the control of the JVM compilers. It will allow the user to apply sets of options depending on which method is being compiled. It also adds the possibility of changing the option sets during run time.
JEP 193: Variable Handles. Define a standard means to invoke the equivalents of java.util.concurrent.atomic and sun.misc.Unsafe operations upon object fields and array elements. Define a standard set of fence operations for fine-grained control of memory ordering (sun.misc.Unsafe provides a non-standard set of fence operations). Define a standard reachability fence operation ensuring a referenced object remains strongly reachable.
JEP 197: Segmented Code Cache. Divide the code cache into distinct segments, each of which contains compiled code of a particular type, in order to improve performance and enable future extensions.
JEP 199: Smart Java Compilation, Phase Two. Improve the sjavac tool so that it can be used by default in the JDK build, and generalize it so that it can be used to build large projects other than the JDK.
JEP 200: The Modular JDK. Use the Java Platform Module System, specified by JSR 376 and implemented by JEP 261, to modularize the JDK.
JEP 201: Modular Source Code. Reorganize the JDK source code into modules, enhance the build system to compile modules, and enforce module boundaries at build time.
JEP 211: Elide Deprecation Warnings on Import Statements. As of Java SE 8, java compilers are required by reasonable interpretations of the Java Language Specification to issue deprecation warnings when a deprecated type is imported by name or when a deprecated member (method, field, nested type) is imported statically. These warnings are uninformative and should not be required. Deprecation warnings at actual uses of deprecated members should remain.
JEP 212: Resolve Lint and Doclint Warnings. The JDK code base contains numerous lint and doclint errors as reported by javac. These warnings should be resolved, at least for the fundamental parts of the platform.
JEP 213: Milling Project Coin. Allow @SafeVargs on private instance methods.Allow effectively-final variables to be used as resources in the try-with-resources statement. Allow diamond with inner classes if the argument type of the inferred type is denotable. Complete the removal, begun in Java SE 8, of underscore from the set of legal identifier names.
JEP 214: Remove GC Combinations Deprecated in JDK 8. Remove the GC combinations that were previously deprecated in JDK 8 via JEP 173.
JEP 215: Tiered Attribution for javac. Implement a new approach, tiered attribution (TA), for type checking in javac to replace the speculative-attribution approach implemented in JDK 8.
JEP 216: Process Import Statements Correctly. Fix javac to properly accept and reject programs regardless of the order of import statements and extends and implements clauses.
JEP 217: Annotations Pipeline 2.0. Redesign the javac annotations pipeline to better address the requirements of annotations and tools that process annotations.
JEP 219: Datagram Transport Layer Security (DTLS). Define an API for Datagram Transport Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347).
JEP 220: Modular Run-Time Images. Restructure the JDK and JRE run-time images to accommodate modules and to improve performance, security, and maintainability. Define a new URI scheme for naming the modules, classes, and resources stored in a run-time image without revealing the internal structure or format of the image. Revise existing specifications as required to accommodate these changes.
JEP 221: Simplified Doclet API. Replace the Doclet API with a simpler design that leverages newer alternative APIs with improved functionality, and update the standard doclet to use it.
JEP 222: jshell: The Java Shell (Read-Eval-Print Loop). Provide an interactive tool to evaluate declarations, statements, and expressions of the Java programming language, together with an API so that other applications can leverage this functionality.
JEP 223: New Version-String Scheme. Revise the JDK's version-string scheme so that it is easier to distinguish major, minor, and security-update releases.
JEP 224: HTML5 Javadoc. Enhance the javadoc tool to generate HTML5 markup.
JEP 225: Javadoc Search. Add a search box to generated API documentation that can be used to search for program elements and tagged words and phrases within the documentation. The search box will appear in the header of all pages that are displayed in the main right hand frame.
JEP 226: UTF-8 Property Files. Define a means for applications to specify property files encoded in UTF-8, and extend the ResourceBundle API to load them.
JEP 227: Unicode 7.0. Upgrade existing platform APIs to support version 7.0 of the Unicode Standard.
JEP 228: Add More Diagnostic Commands. Define additional diagnostic commands, in order to improve the diagnosability of Hotspot and the JDK.
JEP 229: Create PKCS12 Keystores by Default. Transition the default keystore type from JKS to PKCS12.
JEP 231: Remove Launch-Time JRE Version Selection. Remove the ability to request, at JRE launch time, a version of the JRE that is not the JRE being launched.
JEP 232: Improve Secure Application Performance. Improve the performance of applications that are run with a security manager installed.
JEP 233: Generate Run-Time Compiler Tests Automatically. Develop a tool to test the run-time compilers by automatically generating test cases.
JEP 235: Test Class-File Attributes Generated by javac. Create tests that check that all class-file attributes are generated correctly even if such attributes are not used in a regular compile-and-run scenario. Additionally, document any existing such tests.
JEP 236: Parser API for Nashorn. Define a supported API for Nashorn's ECMAScript abstract syntax tree.
JEP 237: Linux/AArch64 Port. Port JDK 9 to Linux/AArch64.
JEP 238: Multi-Release JAR Files. Extend the JAR file format to allow multiple, Java-release-specific versions of class files to coexist in a single archive.
JEP 240: Remove the JVM TI hprof Agent. Remove the hprof agent from the JDK. The useful features of the hprof agent have been superseded by better alternatives.
JEP 241: Remove the jhat Tool. Remove the antiquated jhat tool.
JEP 243: Java-Level JVM Compiler Interface. Instrument the data flows within the JVM which are used by the JIT compiler to allow Java code to observe, query, and affect the JVM's compilation process and its associated metadata
244: TLS Application-Layer Protocol Negotiation Extension
245: Validate JVM Command-Line Flag Arguments
246: Leverage CPU Instructions for GHASH and RSA
247: Compile for Older Platform Versions
248: Make G1 the Default Garbage Collector
249: OCSP Stapling for TLS
250: Store Interned Strings in CDS Archives
251: Multi-Resolution Images
252: Use CLDR Locale Data by Default
253: Prepare JavaFX UI Controls & CSS APIs for Modularization
254: Compact Strings
255: Merge Selected Xerces 2.11.0 Updates into JAXP
256: BeanInfo Annotations
257: Update JavaFX/Media to Newer Version of GStreamer
258: HarfBuzz Font-Layout Engine
259: Stack-Walking API
260: Encapsulate Most Internal APIs
261: Module System
262: TIFF Image I/O
263: HiDPI Graphics on Windows and Linux
264: Platform Logging API and Service
265: Marlin Graphics Renderer
266: More Concurrency Updates
267: Unicode 8.0
268: XML Catalogs
269: Convenience Factory Methods for Collections
270: Reserved Stack Areas for Critical Sections
271: Unified GC Logging
272: Platform-Specific Desktop Features
273: DRBG-Based SecureRandom Implementations
274: Enhanced Method Handles
275: Modular Java Application Packaging
276: Dynamic Linking of Language-Defined Object Models
277: Enhanced Deprecation
278: Additional Tests for Humongous Objects in G1
279: Improve Test-Failure Troubleshooting
280: Indify String Concatenation
281: HotSpot C++ Unit-Test Framework
282: jlink: The Java Linker
283: Enable GTK 3 on Linux
284: New HotSpot Build System
285: Spin-Wait Hints
287: SHA-3 Hash Algorithms
288: Disable SHA-1 Certificates
289: Deprecate the Applet API
290: Filter Incoming Serialization Data
292: Implement Selected ECMAScript 6 Features in Nashorn
294: Linux/s390x Port
295: Ahead-of-Time Compilation

Wie beim Java 8 bildet das OpenJDK die Referenzimplementierung, auf deren Basis das Oracle JDK stehen wird. Das Mercurial Repository ist offen. Change-Sets der Builds dokumentieren die Änderungen.

http://hg.openjdk.java.net/jdk9/jdk9. Source-Repository, unter jdk/file dann alle Pakete mit den Typn
http://openjdk.java.net/projects/jdk9/. Status und Links auf die JEPs
https://jdk9.java.net/download/. Download vom letzten Build

Die Mailing-Listen dokumentieren weiterhin Updates:

Java 9 nutzt für den Compiler die neue Modul-Infrastruktur, weshalb eine IDE angepasst werden muss. Aktuelle Versionen von Eclipse unterstützen längst Java 9, das gleiche gilt für IntelliJ und sogar NetBeans.

Modulsystem Jigsaw

In den letzten Jahren gab es immer Diskussionen um ein Modulsystem. Dabei vermischen sich zwei Dinge: einmal, dass Oracle selbst für das JDK intern ein Modulsystem nutzen möchte und einmal, dass Entwickler selbst ihre Anwendungen modularisieren können, so ähnlich wie es mit OSGi möglich ist. Das Modulsystem http://openjdk.java.net/projects/jigsaw/ war eigentlich soweit fertig, wurde dann aber doch auf Java 9 verschoben.

http://openjdk.java.net/projects/jigsaw/
http://openjdk.java.net/projects/jigsaw/doc/quickstart.html
http://earthly-powers.blogspot.de/2012/06/modular-services-with-openjdk-jigsaw.html
Successful modularity depends on your dependency model
The Open Road: Superpackages (Elliotte Rusty Harold)
Java Language Modularity With Superpackages. Alex Buckley, Andreas Sterbenz. SunOne 2007

Modulsystem Jigsaw

Alle API-Änderungen im Überblick