search
Next stop: Formal Public Review period

Java 9: The draft Public Review Specification is out

Gabriela Motroc
Java 9

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

Transition the default keystore type from JKS to PKCS12. — JEP 229

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)

Define an API for Datagram Transport Layer Security (DTLS) version 1.0 (RFC 4347) and 1.2 (RFC 6347). — JEP 219

OCSP Stapling for TLS

Implement OCSP stapling via the TLS Certificate Status Request extension (section 8 of RFC 6066) and the Multiple Certificate Status Request Extension (RFC 6961). — JEP 249

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

Implement the Java Platform Module System, as specified by JSR 376, together with related JDK-specific changes and enhancements. — JSR 376; JEP 261

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

Author
Gabriela Motroc
Gabriela Motroc is an online editor for JAXenter.com. Before working at S&S Media she studied International Communication Management at The Hague University of Applied Sciences.

Comments
comments powered by Disqus