Java 9

general availability on 2017-09-22

JEPs

Java 9 comes with a vast list of features. There are 91 JEPs listed in the features and schedule page for JDK 9 (see also JDK 9) .

As such a huge list is not easily digestible, I first listed the most important feature in the first section of new features. The remaining features I sorted into aeras of application. The remainder of features, where the are less than three features for an area of application, is listed in section unassorted.

The feature list in section most important new features is certainly biased. It might include features you might not expect in this section, or, on the other hand, some features you might expect in this section might be missing here. However, I assume that for the most features listed in this section there is a common agreement between Java devs that these are the most important features.

new features

the most important new features

compiler

concurrency

documentation

diagnostics

graphics and UI

i18n and encoding

logging

ports

security

unassorted

This section contains new features in areas of application where there are less than three new feature in an area of application.

JDK internal

deprecated

removed

some feature details

JEP 102: Process API Updates

Before JDK 9, getting the PID of a process was tedious, the ceremony to return the PID of a process was specific to the OS the JVM was running on.

JDK 9 offers some updates for working with processes.

The class java.lang.Process class is enhanced to provide the following information about a process:

• process id
• arguments
• command with which the process was invoked
• arguments of the command
• start time
• accumulated cpu time
• user name for the process

The class java.lang.ProcessHandle class offers the same information about a process as listed above for the java.lang.Process class. Additionally, ProcessHandle can return the process' parent, the direct children and all descendants via a stream of ProcessHandles.

ProcessHandles can be used to destroy processes and monitor process liveness. With ProcessHandle.onExit, the asynchronous mechanisms of CompletableFuture can be used to schedule an action to be taken when the process exits.

Access to information about processes and control of processes is subject to security manager permissions and are limited by the normal operating system access controls.

JEP 222: jshell: The Java Shell (Read-Eval-Print Loop)

The JShell API and tool provides a way to interactively evaluate declarations, statements, and expressions of the Java programming language. The JShell state includes an evolving code and execution state. To facilitate rapid investigation and coding, statements and expressions need not occur within a method, and variables and method need not occur within a class.

The jshell tool is a command-line tool with features to ease interaction including: a history with editing, tab-completion, automatic addition of needed terminal semicolons, and configurable predefined imports and definitions.

A jshell guide describing it’s features can be found here.

JEP 269: Convenience Factory Methods for Collections

Constructing a Collection of elements was very verbose in Java, i.e. to construct an unmodifiable Set of Strings, the ceremony was like:

With the convenience factory methods for colĺections, the code above boils down to one statement:

Collections can be constructed from other collections with copy constructors:

An alternative, yet seen less often, is the so-called double brace technique:

The Java 8 Stream API can be used to construct collections, by combining stream factory methods and collectors:

Also provided are fixed-argument overloads for up to ten of elements, i.e. a Map can be populated with a small number of elements in an oneliner, too:

JEP 277: Enhanced Deprecation

The message sent to devs with the @Deprecated annotation was in most cases unclear.

Some people believed that everything that was deprecated is about to be removed or might eventually be removed. But very few deprecated APIs were actually removed, leading some people to believe that nothing would ever be removed. For some people, it was just a don’t-care item.

The Java Language Specification for Java SE 7 does not state anything about the removal of APIs annotated with @Deprecated, instead the intent is defined as follows:

" A program element annotated @Deprecated is one that programmers are discouraged from using, typically because it is dangerous, or because a better alternative exists. "

The Java Language Specification, Java SE 7 Edition, section 9.6.3.6. @Deprecated

In most cases, the intent behind a deprecation is to advice users to not use the deprecated API for new code or while maintaining existing code and migrate any usage of the deprecated API to the most possible extent.

JEP 277: Enhanced Deprecation lists the following reasons for deprecation:

• the API is flawed and is impractical to fix,
• usage of the API is likely to lead to errors,
• the API has been superseded by another API,
• the API is obsolete,
• the API is experimental and is subject to incompatible changes,
• or any combination of the above.

The first two items in the list relate to the “dangerous” case, the following two items relate to the “better alternatives exist” case in the JLS statement about the intent of @Deprecated.

The reason for using @Deprecated because an API is experimental seems rather odd to me. This one looks to me like a stopgap solution and I recommend against using @Deprecated for experimental features.

Often, the exact reasons for deprecating an API are to subtle that they can be expressed as flags. An APIs documentation should describe the reasons for deprecating and it should also discuss potential replacements to help devs migrating away from the deprecated API.

new optional attributes

Java 9 introduces two optional attributes for @Deprecated.

To clarify if a deprecated API is to be removed in the future, the optional attribute of type boolean forRemoval is introduced. The default value is false. Example:

With @Deprecated(forRemoval = false), it can be made clear that no removal in the future is intended. forRemoval also gives you the opportunity to scan for deprecated API in your codebase, that is marked for removal in future versions.

The other introduced optional attribute since is of type String, where the string is in free form, but it is recommended that the string contains the version of the API when it was deprecated. The default value for since is the empty String “”. Example:

reference

JEP 102: Process API Updates

JEP 222: jshell

JEP 269: Convenience Factory Methods for Collections

JEP 277: Enhanced Deprecation