Java 9: The draft Public Review Specification is out
COMING SOON business concept image via Shutterstock
The countdown for Java 9 has officially begun and here’s the proof: Oracle’s Iris Clark announced the availability of the draft Public Review Specification and explained that, if everything goes well, it will be submitted to the JCP Program Management Office (PMO) for the formal Public Review period next week.
Oracle’s Iris Clark announced in a message to the OpenJDK mailing list that the draft Public Review Specification for Java 9 is available. If everyone is pleased with the draft, Clark will submit it to the JCP Program Management Office (PMO) for the formal Public Review period next week.
Clark explained that “the main specification has changed slightly from the EDR, mostly notably with a reduction in the number of APIs proposed for removal in Section 10.” They also noticed that two JEPs (252 – Use CLDR Locale Data by Default; 280 – Indify String Concatenation) had an impact to the SE API, so they were added to the list of features in Sections 5 and 6.
Other changes are the incorporation of Annex 1 (a detailed API specification-change summary), Annex 2 (an annotated API specification showing the exact differences relative to Java SE 8 —JSR 337), Annex 3 (containing draft versions of The Java Language Specification —JLS— and the Java Virtual Machine Specification —JVMS) and Annex 4 (an annotated version of the Java Native Interface Specification — JNI— showing differences relative to Java SE 8).
Let’s have a look at the draft Public Review Specification.
Java 9 Public Review Specification: What’s in it
According to the summary made by Oracle’s Iris Clark and Mark Reinhold, the stars of this release are the introduction of the Java Platform Module System (JSR 376) and the use of that system to modularize the Java SE Platform itself.
The module system addresses two fundamental needs of all large Java applications, namely reliable configuration and strong encapsulation. The application of the module system to the Platform will enable Platform Implementations to be customized for scenarios ranging from small computing devices to dense cloud deployments; to improve security by encapsulating implementation-internal APIs; and to improve performance via more effective ahead-of-time, whole-program optimization techniques.
This release also removes some existing features and APIs, proposes to remove more APIs in the next release and adds a collection of smaller yet significant features.
SEE ALSO: JDK 9 Early Access documentation has been released
Features
The two explained that work on features in the Java SE 9 Reference Implementation, which is the Java Development Kit, version 9 (JDK 9), is organized in terms of JDK Enhancement Proposals (JEPs).
Core Libraries
Convenience Factory Methods for Collections — Define library APIs to make it convenient to create instances of collections and maps with small numbers of elements, so as to ease the pain of not having collection literals in the Java programming language.
— JEP 269
Enhanced Deprecation
Revamp the @Deprecated annotation, and provide tools to strengthen the API life cycle. — JEP 277
Enhanced Method Handles
Enhance the MethodHandle, MethodHandles, and MethodHandles.Lookupclasses of the java.lang.invoke package to ease common use cases and enable better compiler optimizations by means of new MethodHandle combinators and lookup refinement. — JEP 274
Filter Incoming Serialization Data
Allow incoming streams of object-serialization data to be filtered in order to improve both security and robustness. — JEP 290
Indify String Concatenation
Change the static String-concatenation bytecode sequence generated by javac to use invokedynamic calls to JDK library functions. This will enable future optimizations of String concatenation without requiring further changes to the bytecode emitted by javac. — JEP 280
More Concurrency Updates
An interoperable publish-subscribe framework, enhancements to theCompletableFuture API, and various other improvements. — JEP 266
Platform Logging API and Service
Define a minimal logging API which platform classes can use to log messages, together with a service interface for consumers of those messages. A library or application can provide an implementation of this service in order to route platform log messages to the logging framework of its choice. If no implementation is provided then a default implementation based upon the java.util.logging API will be used. — JEP 264
Process API Updates
Improve the API for controlling and managing operating-system processes. — JEP 102
Spin-Wait Hints
Define an API to allow Java code to hint that a spin loop is being executed. — JEP 285
Stack-Walking API
Define an efficient standard API for stack walking that allows easy filtering of, and lazy access to, the information in stack traces. — JEP 259
UTF-8 Property Resource Bundles
Define a means for applications to specify property files encoded in UTF-8, and extend the ResourceBundle API to load them. — JEP 226
Use CLDR Locale Data by Default
Use locale data from the Unicode Consortium’s Common Locale Data Repository (CLDR) by default. — JEP 252
Variable Handles
Define a standard means to invoke the equivalents of variousjava.util.concurrent.atomic and sun.misc.Unsafe operations upon object fields and array elements, a standard set of fence operations for fine-grained control of memory ordering, and a standard reachability-fence operation to ensure that a referenced object remains strongly reachable. — JEP 193
Security
Create PKCS12 Keystores by Default
DRBG-Based SecureRandom Implementations
Implement the three Deterministic Random Bit Generator (DRBG) mechanisms described in NIST 800-90Ar1. — JEP 273
Datagram Transport Layer Security (DTLS)
OCSP Stapling for TLS
TLS Application-Layer Protocol Negotiation Extension
Extend the javax.net.ssl package to support the TLS Application Layer Protocol Negotiation (ALPN) Extension, which provides the means to negotiate an application protocol for a TLS connection. — JEP 244
Client Libraries
Deprecate the Applet API
Deprecate the Applet API, which is rapidly becoming irrelevant as web-browser vendors remove support for Java browser plug-ins. Guide developers to alternative technologies such as Java Web Start or installable applications. — JEP 289
Multi-Resolution Images
Define a multi-resolution image API so that images with resolution variants can easily be manipulated and displayed. — JEP 251
Platform-Specific Desktop Features
Define a new public API to access platform-specific desktop features such as interacting with a task bar or dock, or listening for system or application events. — JEP 272
TIFF Image I/O
Extend the standard set of Image I/O plugins to support the TIFF image format. — JEP 262
Language
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 211
Milling Project Coin
The small language changes included in Project Coin / JSR 334 as part of JDK 7 / Java SE 7 have been easy to use and have worked well in practice. However, a few amendments could address the rough edges of those changes. In addition, using underscore ("_") as an identifier, which generates a warning as of Java SE 8, should be turned into an error in Java SE 9. It is also proposed that interfaces be allowed to have private methods. — JEP 213
Platform
Module System
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 238
New Version-String Scheme
Define a version-string scheme that easily distinguishes major, minor, and security-update releases, and apply it to the JDK. — JEP 223
Unicode 8.0
Upgrade existing platform APIs to support version 8.0 of the Unicode Standard. — JEP 267
XML
XML Catalogs
Develop a standard XML Catalog API that supports the OASIS XML Catalogs standard, v1.1. The API will define catalog and catalog-resolver abstractions which can be used with the JAXP processors that accept resolvers. — JEP 268
If you want to find out which features and APIs have been removed and which APIs have been proposed for removal, check out the draft Public Review Specification.
Leave a Reply