JDK 9 Early Access Release Notes

Last Updated: 2017/05/18

The following is a draft of the Release Notes that will be shipped with JDK 9. Until this version releases the contents are subject to change.


Since build 170  Integrations

core-libs/java.lang.invoke

java.lang.invoke.LambdaMetafactory cannot be constructed

A behavioural change has been made to class java.lang.invoke.LambdaMetafactory so that it is no longer possible to construct an instance. This class only has static methods to create "function objects" (commonly utilized as bootstrap methods) and should not be instantiated. The risk of source and binary incompatibility is very low; analysis of existing code bases found no instantiations.

See JDK-8177153






Since build 168  Integrations

core-libs/java.lang.invoke

MethodHandles.bind obeys protected access rules

The method java.lang.invoke.MethodHandles.bind has been fixed to correctly obey the access rules when binding a receiver object to a protected method.

See JDK-8177146






Since build 167  Integrations

infrastructure

OS_VERSION property in `release` file removed

OS_VERSION property is no longer present in the release file. Scripts or tools that read the release file may need to be updated to handle this change.

See JDK-8175819






Since build 165  Integrations

core-libs/java.lang

Deprecate Object.finalize

The java.lang.Object.finalize method has been deprecated. The finalization mechanism is inherently problematic and can lead to performance issues, deadlocks, and hangs. The java.lang.ref.Cleaner and java.lang.ref.PhantomReference provide more flexible and efficient ways to release resources when an object becomes unreachable. For further information, please see the java.lang.Object.finalize method specification.

See JDK-8165641






Since build 164  Integrations

tools/javadoc(tool)

The old standard doclet is deprecated and will be removed in a future release

The standard doclet is the doclet in the JDK that produces the default HTML-formatted API output. The version that was available in previous releases (com.sun.tools.doclets.standard.Standard) has been replaced by a new version (jdk.javadoc.doclet.Standard). The old version is now deprecated and is subject to removal in a future version of Java SE. For more details, see JEP 221. For more details on the new Doclet API, see [the right external URL].

See JDK-8177484






Since build 163  Integrations

hotspot/runtime

Deprecate FlatProfiler

The VM Option "-Xprof" is deprecated in JDK 9 and will be removed in a future release. The option provides some profiling data for code being executed to standard output. Better data can be gathered with other tools such as Java Flight Recorder and therefore "-Xprof" will no longer be available in a future release.

See JDK-8176098






Since build 162  Integrations

tools/javadoc(tool)

javadoc may exit on non-compliant sources.

Type New behavior Summary: javadoc may exit on non-compliant input sources. Details If any errors are encountered while reading or analyzing the source code, the javadoc tool will treat them as unrecoverable errors and exit. Releases: jdk9

See JDK-8175219






Since build 161  Integrations

tools/javac

Missing unchecked warnings when checking method reference return types

javac does not generate unchecked warnings when checking method reference return types.

import java.util.function.*;
import java.util.*;

class Test {
   void m() {
      IntFunction<List<String>[]> sls = List[]::new; //warning
      Supplier<List<String>> sls = this::l; //warning
   }

   List l() { return null; }
}

Starting from 9, javac will emit a warning when unchecked conversion is required for a method reference to be compatible with a functional interface target.

This change brings the compiler in sync with JLS section 15.13.2:

A compile-time unchecked warning occurs if unchecked conversion was necessary for the compile-time declaration to be applicable, and this conversion would cause an unchecked warning in an invocation context.

and,

A compile-time unchecked warning occurs if unchecked conversion was necessary for the return type R', described above, to be compatible with the function type's return type, R, and this conversion would cause an unchecked warning in an assignment context.

See JDK-8175317






tools/javac

Javac incorrectly allows receiver parameters in annotation methods

javac was erroneously accepting receiver parameters in annotations methods. This implies that tests cases like the one below were being accepted:

@interface MethodRun {
    int value(MethodRun this);
}

The JLS 8, see JLS8 9.6.1, doesn't allow any formal parameter in annotation methods, this extends to receiver parameters. More specifically, the grammar for annotation types does not allow arbitrary method declarations, instead allowing only AnnotationTypeElementDeclarations. The allowed syntax is:

AnnotationTypeElementDeclaration:
{AnnotationTypeElementModifier} UnannType Identifier ( ) [Dims] [DefaultValue];

Note that nothing is allowed between the parentheses.

See JDK-8175198






core-libs/java.lang

java.lang.ref.Reference.enqueue method clears the reference object before enqueuing

java.lang.ref.Reference.enqueue method clears the reference object before it is added to the registered queue. When the enqueue method is called, the referent is cleared and get() method will return null in JDK 9.

Typically when a reference object is enqueued, it is expected that the referent is no longer referenced and is cleared explicitly via the clear method to avoid memory leak. In other words the get method is expected not to be called in common cases once the enqueuemethod is called. In the case when the get method from an enqueued reference object and existing code attempts to access members of the referent object, NullPointerException may be thrown. Such code will need to be updated.

See JDK-8175797






Since build 160  Integrations

security-libs/java.security

keytool now prints warnings when reading or generating cert/cert req using weak algorithms

With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When the -trustcacerts option is specified or the cacerts keystore is being directly operated on, keytool will not print a warning for certificates in the cacerts keystore that have been signed with a weak signature algorithm.

Precisely, an algorithm or a key is weak if it matches the value of the jdk.certpath.disabledAlgorithms security property defined in the conf/security/java.security file.

See JDK-8171319






Since build 158  Integrations

core-libs/java.rmi

rmic -Xnew option is disabled

The -Xnew option to rmic, has been disabled for this release

See JDK-8146299






Since build 157  Integrations

security-libs/java.security

Fix denyAfter and usage types for security properties

A new constraint named 'usage' has been added to the 'jdk.certpath.disabledAlgorithms' security property, that when set, restricts the algorithm if it is used in a certificate chain for the specified usage(s). Three usages are initially supported: 'TLSServer' for restricting authentication of TLS server certificate chains, 'TLSClient' for restricting authentication of TLS client certificate chains, and 'SignedJAR' for restricting certificate chains used with signed JARs. This should be used when disabling an algorithm for all usages is not practical. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, to disable SHA1 for TLS server and client certificate chains, add the following to the property: "SHA1 usage TLSServer TLSClient"

The 'denyAfter' constraint has been added to the 'jdk.jar.disabledAlgorithms' security property. When set, it restricts the specified algorithm if it is used in a signed JAR after the specified date, as follows:

a. if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date

b. if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date.

For example, to restrict usage of SHA1 in jar files signed after January 1, 2018, add the following to the property: "SHA1 denyAfter 2018-01-01".

See JDK-8160655






Since build 156  Integrations

core-libs

Exported elements referring to inaccessible types in java.naming

The javax.naming.CompoundName, an extensible type, has a protected member, 'impl' whose type, javax.naming.NameImpl, is package-private. This is a long standing issue where an inaccessible implementation type has mistakenly made its way into the public Java SE API.

The new javac lint option javac -Xlint helped identify this issue. In Java SE 9, this protected member has been removed from the public API.

Compatibility:

Since the type of the member is package-private it cannot be directly referenced by non-JDK code. The member type does not implement or extend any super type directly, therefore any non-JDK subtype of javax.naming.CompoundName could only refer to this member as Object. It is possible that such a subtype might invoke the toString, or any of Object's methods on this member, or even synchronize on it. In such a case such subtypes of javax.naming.CompoundName will require updating.

Source incompatible:

Code making a static reference to the member will fail to compile, e.g. error: impl has private access in CompoundName

Binary incompatible:

Previously compiled code executed with 9, accessing the member directly will fail, e.g. java.lang.IllegalAccessError: tried to access field javax.naming.CompoundName.impl from class CompoundName$MyCompoundName

See JDK-8167178






hotspot/compiler

Emulate client build on platforms with reduced virtual address space

The 32-bit Client VM was removed from linux-x86 and Windows. As a result, the -client flag is ignored with 32-bit versions of Java on this platform. The 32-bit Server VM is used instead. However, due to limited virtual address space on Windows in 32-bit mode, by default the Server VM emulates the behavior of the Client VM and only uses the C1 JIT compiler, Serial GC, 32Mb CodeCache. To revert to server mode, the flag -XX:{+|-}TieredCompilation can be used. On linux-x86 there is no Client VM mode emulation.

See JDK-8166002






Since build 155  Integrations

core-libs/java.util:i18n

Provide a better migration path for ResourceBundleControlProvider

In releases through JDK 8, SPI implementations of java.util.spi.ResourceBundleControlProvider were loaded using Java Extension Mechanism. In JDK 9, this mechanism is no longer available. Instead, SPI implementations may be placed on an application's class path.

See JDK-8172365






Since build 154  Integrations

tools/visualvm

Visual VM removed in JDK9

Visual VM is a tool that provides information about code running on a Java Virtual Machine. It was provided with Oracle JDK 6, Oracle JDK 7, and Oracle JDK 8.

Starting from JDK 9, the tool (jvisualvm) is no longer included in Oracle JDK. Users can still download the tool from the official project website at https://visualvm.github.io

See JDK-8160881






security-libs/java.security

Update SecurityManagercheckPackageAccess to restrict non-exported JDK packages by default

The implementation of the checkPackageAccess and checkPackageDefinition methods of java.lang.SecurityManager now automatically restrict all non-exported packages of JDK modules loaded by the platform class loader or its ancestors. This is in addition to any packages listed in the package.access and package.definition security properties. A "non-exported package" refers to a package that is not exported to all modules. Specifically, it refers to a package that either is not exported at all by its containing module or is exported in a qualified fashion by its containing module.

If your application is running with a SecurityManager, it will need to be granted an appropriate accessClassInPackage.{package} RuntimePermission to access any internal JDK APIs (in addition to specifying an appropriate --add-exports option). If the application has not been granted access, a SecurityException will be thrown.

Note that an upgraded JDK module may have a different set of internal packages than the corresponding system module, and therefore may require a different set of permissions.

The package.access and package.definition properties no longer contain internal JDK packages that are not exported. Therefore, if an application calls Security.getProperty("package.access"), it will not include the builtin non-exported JDK packages.

Also, when running under a SecurityManager, an attempt to access a type in a restricted package that does not contain any classes now throws a ClassNotFoundException instead of an AccessControlException. For example, loading sun.Foo now throws a ClassNotFoundException instead of an AccessControlException because there are no classes in the sun package.

See JDK-8055206






Since build 151  Integrations

client-libs/javax.swing

Tab key should move to focused button in a button group

The focus behavior of Swing toggle button controls (JRadioButton and JCheckBox) changed when belong to a button group. Now if the input focus is requested to any toggle button in the group through either focus traversal or window activation the currently selected toggle button is focused regardless of the focus traversal policy used in the container. If the selected toggle button is not eligible to be a focus owner the focus is set according to the focus traversal policy.

See JDK-8074883






tools/javac

Add compile-time check for invalid or out-of-range ConstantValue attributes

The classfile format (see JVMS section 4.7.2) defines an attribute called ConstantValue which is used to describe the constant value associated with a given (constant) field. The layout of this attribute is as follows:

ConstantValue_attribute {
    u2 attribute_name_index;
    u4 attribute_length;
    u2 constantvalue_index;
}

Historically, javac has never performed any kind of range validation of the value contained in the constant pool entry at constantvalue_index. As such, it is possible for a constant field of type e.g. boolean to have a constant value other than 0 or 1 (the only legal values allowed for a boolean). Starting from 9, javac will start detecting ill-formed ConstantValue attributes, and report errors if out-of-range values are found.

See JDK-8171132






core-libs/java.lang:reflect

Class.getMethod and Class.getMethods more accurately follow inheritance rules

The javadoc for the Class.getMethod and Class.getMethods refer to the definition of inheritance in the Java Language Specification. Java SE 8 changed these rules in order to support default methods and reduce the number of redundant methods inherited from superinterfaces (see JLS 8, 8.4.8).

Class.getMethod and Class.getMethods were not updated with the 8 release to match the new inheritance definition (both may return non-inherited superinterface methods). The implementation has now been changed to filter out methods that are not members of the class.

See JDK-8029459






Since build 150  Integrations

xml/jaxp

Revamping the pretty print feature for Transformer and LSSerializer

The JAXP library through the Transformer and LSSerializer supports a pretty print feature that can format the output by adding whitespaces and newlines to produce a more readable form of an XML document. As of the JDK 9 release, this feature has been enhanced to generate a format similar to that of the major web browsers. In addition, the xml:space attribute as defined in the XML specification (https://www.w3.org/TR/2006/REC-xml-20060816/#sec-white-space) is now supported.

The Pretty-Print feature does not define the actual format. The output format can change over time or vary from implementation to implementation, and therefore should not be relied on for exact text comparison. It is recommended that such applications turn off the Pretty-Print feature and perform an XML to XML comparison.

See JDK-8087303






client-libs/javax.accessibility

Three com.sun.java.accessibility.utils internal fields are now private

Three static fields exposing event listener instances whose types are internal and intended use was internal are now made private. These are very unlikely to have been used by many applications as until recently they were shipped only as an unbundled component.

See JDK-8167182






hotspot/gc

Deprecate the flag -XXExplicitGCInvokesConcurrentAndUnloadsClasses

The flag -XX:ExplicitGCInvokesConcurrentAndUnloadsClasses has been deprecated and will be removed in a future release. A user can enable the same functionality by setting the two flags -XX:+ExplicitGCInvokesConcurrent and -XX:+ClassUnloadingWithConcurrentMark.

See JDK-8170388






Since build 147  Integrations

xml/jaxp

OOME caused by very large CDATA section in XML document can now be avoided

An event-based XML parsers may return character data in chunks.

SAX specification: states that SAX parsers may return all contiguous character data in a single chunk, or they may split it into several chunks.

StAX specification: did not specify explicitly.

The JDK implementation before JDK 9 returns all character data in a CData section in a single chunk by default. As of JDK 9, an implementation-only property jdk.xml.cdataChunkSize is added to instruct a parser to return the data in a CData section in a single chunk when the property is zero or unspecified, or in multiple chunks when it is greater than zero. The parser will split the data by linebreaks, and any chunks that are larger than the specified size to ones that are equal to or smaller than the size.

The property jdk.xml.cdataChunkSize is supported through the following means:

  1. through the SAX or StAX API, that is SAXParser or XMLReader for SAX, and XMLInputFactory for StAX. If the property is set, its value will be used in preference over any of the other settings.
  2. as a system property. The value set in the system property will overwrite that in jaxp.properties, but may be overridden by the API setting above.
  3. in the jaxp.properties file. The value in jaxp.properties may be overridden by the system property or an API setting.
See JDK-8158619






core-libs/java.time

Return unmodifiable set of zone IDs to optimize ZoneIdPrinterParser

The performance of java.time.zone.ZoneRulesProvider.getAvailableZoneIds() is improved by returning an unmodifiable set of zone ids; previously the set was modifiable.

See JDK-8066291






core-libs/java.lang

Spec update of ClassLoader.getResourceXXXXX() @throws NPE

The spec of the following java.lang.ClassLoader methods for locating a resource by name are updated to throw NullPointerException when the specified name is null:

  getResource(String)
  getResourceAsStream(String)
  getResources(String)

Custom class loader implementations that override these methods should be updated accordingly to conform to this spec.

See JDK-8136831






Since build 146  Integrations

core-libs/java.lang.invoke

invokedynamic implementation should not wrap Errors

The invokedynamic byte code instruction is no longer specified by the Java Virtual Machine Specification to wrap any Throwable thrown during linking in java.lang.invoke.BootstrapMethodError, which is then thrown to the caller.

If during linking an instance of Error, or a subclass of, is thrown then that Error is no longer wrapped and is thrown directly to the caller. Any other instance of Throwable, or subclass of, is still wrapped in java.lang.invoke.BootstrapMethodError.

This change in behaviour ensures that errors such as OutOfMemoryError or ThreadDeath are thrown unwrapped and may be acted on or reported directly, thereby enabling more uniform replacement of byte code with an invokedynamic instruction whose call site performs the same functionality as the replaced byte code (and may throw the same errors).

See JDK-8166974






Since build 145  Integrations

tools/launcher

The launcher no longer uses ergonomics to select the VM

In previous releases, on platforms that supported more than one VM, the launcher could use ergonomics to select the Server VM over the Client VM. Ergonomics would identify a "server-class" machine based on the number of CPUs and the amount of memory. With modern hardware platforms most machines are identified as server-class, and so now, only the Server VM is provided on most platforms. Consequently the ergonomic selection is redundant and has been removed. Users are advised to use the appropriate launcher VM selection flag on those systems where multiple VMs still exist.

See JDK-8169001






javafx/graphics

Stage background is now filled with Scene fill color

Starting with the JDK 9 release, a Stage on Mac and Linux platforms will be initially filled using the Fill property of the Scene if its Fill is a Color. An average color, computed within the stops range, will be used if the Fill is a LinearGradient or RadialGradient. Previously, it was initially filled with WHITE, irrespective of the Fill in the Scene. This change in behavior will reduce the flashing that can be seen with a dark Scene background, but applications should be aware of this change in behavior so they can set an appropriate Fill color for their Scene.

See JDK-8088179






Since build 144  Integrations

core-libs/java.rmi

RMI server-side multiplex protocol has been disabled

The RMI multiplex protocol is disabled by default. It can be re-enabled by setting the system property "sun.rmi.transport.tcp.enableMultiplexProtocol" to "true".

See JDK-8158963






Since build 143  Integrations

security-libs/org.ietf.jgss:krb5

rcache interop with krb5-1.15

The hash algorithm used in the Kerberos 5 replay cache file (rcache) is updated from MD5 to SHA256 with this change. This is also the algorithm used by MIT krb5-1.15. This change is interoperable with earlier releases of MIT krb5, which means Kerberos 5 acceptors from JDK 9 and MIT krb5-1.14 can share the same rcache file.

A new system property named jdk.krb5.rcache.useMD5 is introduced. If the system property is set to "true", JDK 9 will still use the MD5 hash algorithm in rcache. This is useful when both of the following conditions are true: 1) the system has a very coarse clock and has to depend on hash values in replay attack detection, and 2) interoperability with earlier versions of JDK for rcache files is required. The default value of this system property is "false".

See JDK-8168518






client-libs/javax.swing

Trackpad scrolling of text on OS X 10.12 Sierra is very fast

The MouseWheelEvent.getWheelRotation() method returned rounded native NSEvent deltaX/Y events on Mac OS X. The latest macOS Sierra 10.12 produces very small NSEvent deltaX/Y values so rounding and summing them leads to the huge value returned from the MouseWheelEvent.getWheelRotation(). The JDK-8166591 fix accumulates NSEvent deltaX/Y and the MouseWheelEvent.getWheelRotation() method returns non-zero values only when the accumulated value exceeds a threshold and zero value. This is compliant with the MouseWheelEvent.getWheelRotation() specification:

https://docs.oracle.com/javase/8/docs/api/java/awt/event/MouseWheelEvent.html#getWheelRotation--

Returns the number of "clicks" the mouse wheel was rotated, as an integer. A partial rotation may occur if the mouse supports a high-resolution wheel. In this case, the method returns zero until a full "click" has been accumulated.

For the precise wheel rotation values, use the MouseWheelEvent.getPreciseWheelRotation() method instead.

See JDK-8166591






hotspot/gc

UseAutoGCSelectPolicy has been deprecated

This option was deprecated in JDK 9, along with the -XX:AutoGCSelectPauseMillis option.

See JDK-8166461






hotspot/gc

AutoGCSelectPauseMillis has been deprecated

This option was deprecated in JDK 9, following the deprecation of the -XX:+UseAutoGCSelectPolicy option.

See JDK-8166461






Since build 141  Integrations

xml/javax.xml.transform

XSLT stylesheets with erroneously placed import elements are now rejected

In accordance with XSL Transformations (XSLT) Version 1.0 (http://www.w3.org/TR/xslt), the xsl:import element is only allowed as a top-level element. The xsl:import element children must precede all other element children of an xsl:stylesheet element, including any xsl:include element children.

The JDK implementation has previously allowed the xsl:import element erroneously placed anywhere in a stylesheet. This issue has been fixed in the JDK 9 release. The JDK implementation now rejects any XSLT stylesheets with erroneously placed import elements.

See JDK-8058152






Since build 140  Integrations

core-libs/java.io

Remove pathname canonicalization from FilePermission

Prior to JDK 9, creating a FilePermission object canonicalized its pathname, and the implies and equals methods were based on this canonicalized pathname. For example, if "file" and "/path/to/current/directory/file" point to the same file in the file system, two FilePermission objects from these pathnames are equal and imply each other if their actions are also the same.

In JDK 9, the pathname will not be canonicalized by default. This means two FilePermission objects will not equal each other if one uses an absolute path and the other a relative path, or one uses a symbolic link and the other the target, or one uses a Windows long name and the other a DOS-style 8.3 name, even if they point to the same file in the file system.

A compatibility layer has been added to ensure that granting a FilePermission for a relative path will still permit applications to access the file with an absolute path (and vice versa). This works for the default Policy provider and the limited doPrivileged (http://openjdk.java.net/jeps/140) calls. For example, although a FilePermission on a file with a relative pathname of "a" no longer implies a FilePermission on the same file with an absolute pathname of "/pwd/a" (suppose "pwd" is the current working directory), granting code a FilePermission to read "a" allows that code to also read "/pwd/a" when a Security Manager is enabled. This compatibility layer does not cover translations between symbolic links and targets, or Windows long names and DOS-style 8.3 names, or any other different name forms that can be canonicalized to the same name.

A system property named jdk.io.permissionsUseCanonicalPath has been introduced. When it is set to "true", FilePermission will canonicalize its pathname as it did before JDK 9. The default value of this property is "false".

An experimental system property named jdk.security.filePermCompat has also been introduced. When set to "true", the compatibility layer described above will also apply to third-party Policy implementations. The default value of this property is "false".

See JDK-8164705






Since build 137  Integrations

hotspot/runtime

Enforce format checks for NameAndType strings

This change enforces the unqualified name format checks for NameAndType strings as outlined in the JVM specification sections 4.4.6 and 4.2.2, meaning that some illegal names and descriptors that users may be utilizing in their classfiles will now be caught with a Class Format Error. This includes format checking for all strings under non-referenced NameAndType's. Users will see a change if they (A) are using Java classfile version 6 or below and have an illegal NameAndType descriptor with no Methodref or Fieldref reference to it; or (B) are using any Java classfile version and have an illegal NameAndType name with no Methodref or Fieldref reference to it.

In both (A) and (B) the users will now receive a ClassFormatError for those illegal strings, which is an enforcement of unqualified name formats as delineated in JVMS 4.2.2.

See JDK-8161224






Since build 136  Integrations

core-svc/java.lang.instrument

Agent JAR added to app class loader rather than system class loader when running with -Djava.system.class.loader

When running a java application with the options "-javaagent:myagent.jar -Djava.system.classloader=MyClassLoader", myagent.jar is added to the custom system class loader rather than the application class loader.

In addition, the java.lang.instrument package description has a small update making it clear that a custom system class loader needs to define appendToClassPathForInstrumentation in order to load the agent at startup. Before custom system class loaders were required to implement this method only if the agents are started in the live phase (Agent_OnAttach).

See JDK-8160950






Since build 135  Integrations

core-libs

Modified HttpURLConnection behavior when no suitable proxy is found

The behavior of HttpURLConnection when using a ProxySelector has been modified with this JDK release. HttpURLConnection use to fall back to a DIRECT connection attempt if the configured proxy(s) failed to make a connection. This release introduces a change whereby no DIRECT connection will be attempted in such a scenario. Instead, the HttpURLConnection.connect() method will fail and throw an IOException which occurred from the last proxy tested.

See JDK-8161016






tools/javac

Compiler will emit a warning if deprecated javadoc tag is used without @Deprecated annotation

If the javadoc deprecated tag is used on an element without it also being deprecated using the @Deprecated annotation, the compiler will by default produce a new warning to this effect.

The new warning can be suppressed either by adding the command line option -Xlint:-dep-ann to the javac command line or by using @SuppressWarnings("dep-ann") annotation (as with any other warning-suppressing annotation, it is always a good practice to add such an annotation as close to the member being deprecated as possible).

In a future version of Java SE, the compiler may no longer treat @deprecated javadoc tag as indicating formal deprecation.

See JDK-8164073






Since build 131  Integrations

core-libs/java.lang:reflect

for Annotation toString output not reusable for source input

The exact toString output of an annotation is deliberately not specified; from java.lang.annotation.Annotation.toString():

Returns a string representation of this annotation. The details of the representation are implementation-dependent [...]

Previously, the toString format of an annotation did not output certain information in a way that would be usable for a source code representation of an annotation, string values were not surrounded by double quote characters, array values were surrounded by brackets ("[]") rather than braces ("{}"), etc.

As a behavioral change, the annotation output has been updated to be faithful to a source code representation of the annotation.

See JDK-8162817






hotspot/svc

'jsadebugd' command has been replaced by 'jhsdb debugd' command.

The jsadebugd command to start remote debug server can now be launched from the common SA launcher jhsdb .

The new command to start remote debug server is jhsdb debugd .

See JDK-8160817






Since build 130  Integrations

security-libs/java.security

Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=true

The following pre-1.2 deprecated java.lang.SecurityManager methods and fields have been marked with forRemoval=true: the inCheck field, and the getInCheck, classDepth, classLoaderDepth, currentClassLoader, currentLoadedClass, inClass, and inClassLoader methods. This field and methods should no longer be used and are subject to removal in a future version of Java SE.

See JDK-8161506






security-libs/java.security

De-privileged module permissions granted by default

When using a SecurityManager, the permissions required by JDK modules are granted by default, and are not dependent on the policy.url properties that are set in the java.security file.

This also applies if you are setting the java.security.policy system property with either the '=' or '==' option.

See JDK-8159752






security-libs/javax.net.ssl

Deprecate methods that reference javax.security.cert APIs

The java.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain and java.net.ssl.SSLSession.getPeerCertificateChain methods have been deprecated. New applications should use the getPeerCertificates method instead.

See JDK-8161898






core-libs/java.time

Changing the boundaries specified by ChronoField.EPOCH_DAY

Boundaries specified by java.time.temporal.ChronoField.EPOCH_DAY have been corrected to match the epoch day of LocalDate.MIN and LocalDate.MAX

See JDK-8160681






Since build 127  Integrations

client-libs/javax.swing

Closing the ProgressMonitor dialog

The ProgressMonitor dialog can be closed in following ways :

  1. 'Cancel' button is pressed
  2. Dialog Close button is pressed
  3. Escape key is pressed

If the ProgressMonitor dialog is closed, ProgressMonitor.isCanceled() method used to return 'true' in only cases (1) and (2) above. This fix corrects the behavior where ProgressMonitor.isCanceled() method will return 'true' in case the ProgressMonitor dialog is closed by pressing Escape key.

There is low compatibility impact of this fix : This change may impact user code that (incorrectly) assumes ProgressMonitor.isCanceled() will return false even if the ProgressMonitor dialog is closed as a result of pressing Escape key. Also, with this change, now there is no way to get the ProgressMonitor dialog out of way whilst having progress continue.

See JDK-8065861






security-libs/javax.crypto

Remove the ExemptionMechanism.finalize() method

The javax.crypto.ExemptionMechanism.finalize() method has been removed from both the specification and the implementation.

See JDK-8159009






hotspot/compiler

Compilers accept modification of final fields outside initializer methods

According to the Java VM Specification, final fields can be modified by the putfield byte code instruction only if the instruction appears in the instance initializer method <init> of the field's declaring class. Similar, static final fields can be modified by a putstatic instruction only if the instruction appears in the class initializer method <clinit> of the field's declaring class. With the JDK 9 release, the HotSpot VM fully enforces the previously mentioned restrictions, but only for class files with version number >= 53. For class files with version numbers < 53, restrictions are only partially enforced (as it is done by releases preceding JDK 9). That is, for class files with version number < 53 final fields can be modified in any method of the class declaring the field (not only class/instance initializers).

See JDK-8157181






security-libs/javax.net.ssl

Improve the default strength of EC in JDK.

To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the "jdk.certpath.disabledAlgorithms" Security Property) and SSL/TLS/DTLS connections (via the "jdk.tls.disabledAlgorithms" Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192").

EC curves less than 256 bits are removed from the SSL/TLS/DTLS implementation in JDK. The new System Property, "jdk.tls.namedGroups", defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example:

jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1"

Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties.

See JDK-8148516






security-libs/javax.net.ssl

Deprecate the javax.security.cert API

The javax.security.cert API has been deprecated. The classes in this package should no longer be used. The java.security.cert package contains suitable replacements.

See JDK-8157712






core-libs/java.util:collections

List.spliterator should optimize for RandomAccess lists

Previously the default implementation of List.spliterator derived a Spliterator from the List's iterator, which is poorly splitting and that affects the performance of a parallel stream returned by List.parallelStream. The default implementation of List.spliterator now returns an optimal splitting Spliterator implementation for List implementations that implement java.util.RandomAccess. As a result parallel stream performance may be improved for third-party List implementations, such as those provided by Eclipse collections, that do not override List.spliterator for compatibility across multiple major versions of the Java platform. This enhancement is a trade-off. It requires that the List.get method, of such lists implementing RandomAccess, have no side-effects, ensuring safe concurrent execution of the method when parallel stream pipeline is executed.

See JDK-8158365






Since build 126  Integrations

core-libs/java.util.logging

A new configurable property in logging.properties java.util.logging.FileHandler.maxLocks

A new "java.util.logging.FileHandler.maxLocks" configurable property is added to java.util.logging.FileHandler.

This new logging property can be defined in the logging configuration file and makes it possible to configure the maximum number of concurrent log file locks a FileHandler can handle. The default value is 100.

In a highly concurrent environment where multiple (more than 101) standalone client applications are using the JDK Logging API with FileHandler simultaneously, it may happen that the default limit of 100 is reached, resulting in a failure to acquire FileHandler file locks and causing an IO Exception to be thrown. In such a case, the new logging property can be used to increase the maximum number of locks before deploying the application.

If not overridden, the default value of maxLocks (100) remains unchanged. See java.util.logging.LogManager and java.util.logging.FileHandler API documentation for more details.

See JDK-8153955






security-libs/java.security

Deprecate the java.security.acl API

The java.security.acl API has been deprecated. The classes in this package should no longer be used. The java.security package contains suitable replacements. See Policy and related classes for details.

See JDK-8157847






security-libs/java.security

Deprecate the java.security.Certificate API with forRemoval=true

The deprecated java.security.Certificate API has been marked with forRemoval=true. The class should no longer be used and is subject to removal in a future version of Java SE.

See JDK-8157707






docs/guides

The JNI function DetachCurrentThread must tolerate pending exceptions

The JNI function DetachCurrentThread has been added to the list of JNI functions that can safely be called with an exception pending. The HotSpot Virtual Machine has always supported this as it reports that the exception occurred in a similar manner to the default handling of uncaught exceptions at the Java level. Other implementations are not obligated to do anything with the pending exception.

See JDK-8155881






security-libs

Deprecate the java.security.{Identity,IdentityScope,Signer} APIs with forRemoval=true

The deprecated java.security.Identity, java.security.IdentityScope and java.security.Signer classes have been marked with 'forRemoval=true'. These classes should no longer be used and are subject to removal in a future version of Java SE.

See JDK-8157730






core-libs/java.util.jar

java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a '/' ended entry name for directory entry

java.util.zip.ZipEntry API doc specifies "A directory entry is defined to be one whose name ends with a '/'". However, in previous JDK releases java.util.zip.ZipFile.getEntry(String entryName) may return a ZipEntry instance with an entry name that does not end with '/' for an existing zip directory entry when the passed in argument entryName does not end with a '/' and there is a matching zip directory entry with name entryName + '/' in the zip file. With JDK 9 the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with '/' for any zip directory entry.

See JDK-6233323






Since build 125  Integrations

core-libs/java.net

The netdoc URL protocol Handler is removed

The netdoc protocol handler has been removed in JDK 9. Code that attempts to construct a java.net.URL with the netdoc protocol, for example "netdoc:http://foo.com/index.html" will throw a MalformedURLException.

The netdoc protocol was used to point to network documents either on the local file system or externally through an HTTP URL. This capability is essentially defunct and is not supported by Safari, Firefox, and other major browsers.

See JDK-8154234






core-libs/java.net

Platforms without multicasting support

In Java SE 9 the requirement to support multicasting has been somewhat relaxed, in order to support a small number of platforms where multicasting is not available. The specification for the java.net.MulticastSocket::joinGroup and the java.nio.channels.MulticastChannel::join methods has been updated to indicate that an UnsupportedOperationException will be thrown if invoked on a platform that does not support multicasting.

There is no impact to Oracle JDK platforms, since they do support multicasting.

See JDK-8157166






Since build 124  Integrations

client-libs

No longer possible to create System L&F via reflection

It has been observed that applications have been using reflection to create internal Swing L&Fs - system L&Fs such as The Windows L&F Class.forName(" com.sun.java.swing.plaf.windows.WindowsLookAndFeel")

These classes are internal to the JDK and applications should have always treated them as such. In JDK 9, the module system means that these classes are not visible to applications.

Applications which need to create a system L&F must instead use the new method : javax.swing.UIManager.createLookAndFeel(String name);

See JDK-8136366






tools/javac

missing error in qualified default super call

Javac was not in sync with JLS 8 §15.12.1, specifically:

If the form is TypeName . super . [TypeArguments] Identifier, then: ...

Let T be the type declaration immediately enclosing the method invocation. It is a compile-time error if I is not a direct superinterface of T, or if there exists some other direct superclass or direct superinterface of T, J, such that J is a subtype of I.

So javac was not issuing a compiler error for cases like:

interface I {
    default int f(){return 0;}
}

class J implements I {}

class T extends J implements I {
    public int f() {
        return I.super.f();
    }
}

The compiler had some checks for method invocations of the form:

TypeName . super . [TypeArguments] Identifier

but there was one issue. If TypeName is an interface I and T is the type declaration immediately enclosing the method invocation, the compiler must issue a compile-time error if there exists some other direct superclass or superinterface of T, let's call it J such that J is a subtype of I, as in the example above.

See JDK-8058244






Since build 123  Integrations

javafx/other

JavaFX impl_* methods have been removed

Several deprecated and undocumented "impl_*" methods have been removed from JDK 9.

In prior releases, many public JavaFX classes in exported packages had public or protected implementation methods that were named with "impl_*" in the name, marked as "@Deprecated" with the stated intention of removing them, and hidden from the API documentation with the "@treatAsPrivate" javadoc tag.

These methods were never supported and were not intended to be used by applications. JavaFX applications that were using these undocumented methods will need to stop calling them.

See JDK-8144585






core-libs/java.util.logging

java.util.logging.FormatterformatMessage API specification has been clarified, and its implementation fixed.

java.util.logging.Formatter.formatMessage API specification specified that MessageFormat would be called if the message string contained "{0". In practice MessageFormat was called if the message string contained either "{0", "{1", "{2" or "{3".

In Java SE 9, the specification and implementation of this method have been changed to call MessageFormat if the message string contains "{<digit>", where <digit> is in [0..9].

In practice, this should be transparent for calling applications.

The only case where an application might see a behaviour change is if the application passes a format string that does not contain any formatter of the form "{0", "{1", "{2" or "{3", but contains "{<digit>" with <digit> within [4..9], along with an array of parameters that contains at least <digit>+1 elements, and depends on MessageFormat not to be called. In that case the method will return a formatted message instead of the format string.

See JDK-8153666






Since build 122  Integrations

core-libs

JDK 9 supports CLDR version 29

To track CLDR 29 Release note.

See JDK-8145136






hotspot/runtime

Additional consistency checks for JVM_CONSTANT_Methodref and JVM_CONSTANT_InterfaceMethodref

The JVM has been fixed to check that the constant pool types JVM_CONSTANT_Methodref or JVM_CONSTANT_InterfaceMethodref are consistent with the type of method referenced. These checks are made during method resolution and are also checked for methods that are referenced by JVM_CONSTANT_MethodHandle.

If consistency checks fail an IncompatibleClassChangeError is thrown.

javac has never generated inconsistent constant pool entries, but some bytecode generating software may. In many cases, if ASM is embedded in the application, upgrading to the latest version ASM 5.1 resolves the exception. After upgrading ASM, be sure to replace all uses of deprecated functions with calls to the new functions, particularly new functions that pass a boolean whether the method is an interface method: visitMethodInsn and Handle.

See JDK-8145148






core-libs/java.util

Default locale in java.util.Formatter related classes.

The specification of the default locales used in Formatter related classes has been clarified to designate the default locale for formatting (Locale.Category.FORMAT).

See JDK-8146156






Since build 120  Integrations

core-libs/java.lang:class_loading

De-synchronize java.util.Properties getter methods

java.util.Properties is a subclass of the legacy Hashtable class, which synchronizes on itself for any access. System properties are stored in a Properties object. They are a common way to change default settings, and sometimes must be read during classloading.

System.getProperties() returns the same Properties instance accessed by the system, which any application code might synchronize on. This situation has lead to deadlocks in the past, such as 6977738.

The Properties class has been updated to store its values in an internal ConcurrentHashMap (instead of using the inherited Hashtable mechanism), and its getter methods and legacy Enumerations are no longer synchronized. This should reduce the potential for deadlocks. It also means that since Properties' Iterators are now generated by ConcurrentHashMap, they don't fail-fast - ConcurrentModificationExceptions are no longer thrown.

See JDK-8029891






security-libs/java.security

New default -sigalg for jarsigner and keytool

Default signature algorithms for jarsigner and keytool are determined by both the algorithm and the key size of the private key which makes use of comparable strengths as defined in Tables 2 and 3 of NIST SP 800-57 Part 1-Rev.4. Specifically, for a DSA or RSA key with a key size greater than 7680 bits, or an EC key with a key size greater than or equal to 512 bits, SHA-512 will be used as the hash function for the signature algorithm. For a DSA or RSA key with a key size greater than 3072 bits, or an EC key with a key size greater than or equal to 384 bits, SHA-384 will be used. Otherwise, SHA-256 will be used. The value may change in the future.

See JDK-8138766






javafx/application-lifecycle

Deprecate HostServices.getWebContext method with forRemoval=true

The HostServices.getWebContext method is deprecated in JDK 9 and is marked as forRemoval=true indicating that it will be removed in a future version of the JDK. Applets are deprecated in JDK 9, and this method is only used when running an FX application as an Applet in a browser.

See JDK-8156963






core-svc/java.lang.management

Changes in logging interface in MXBean

In Java SE 9 the java.util.logging.LoggingMXBean interface is deprecated in favor of the java.lang.management.PlatformLoggingMXBean interface. The java.util.logging.LogManager.getLoggingMXBean() method is also deprecated in favor of java.lang.mangement.ManagementFactory.getPlatformMXBean(PlatformLoggingMXBean.class).

The concrete implementation of the logging MXBean registered in the MBeanServer and obtained from the ManagementFactory will only implement java.lang.management.PlatformLoggingMXBean, and no longer java.util.logging.LoggingMXBean. It must be noted that PlatformLoggingMXBean and LoggingMXBean attributes are exactly the same. The PlatformLoggingMXBean interface has all the methods defined in LoggingMXBean, and so PlatformLoggingMXBean by itself provides the full management capability of logging facility.

This should be mostly transparent to remote and local clients of the API.

Compatibility:

Calls to ManagementFactory.newPlatformMXBeanProxy(MBeanServerConnection, ObjectName, java.util.logging.LoggingMXBean.class) and calls to JMX.newMXBeanProxy(MBeanServerConnection, ObjectName, java.util.logging.LoggingMXBean.class) will continue to work as before.

Remote clients running any version of the JDK should see no changes, except for the interface name in MBeanInfo, and the change in isInstanceOf reported in 1. and 2. below.

The behavioral change and source incompatibility due to this change are as follows:

  1. ManagementFactory.getPlatformMBeanServer().isInstanceOf(ObjectName, "java.util.logging.LoggingMXBean") will now return 'false' instead of 'true'.

    If an application depends on this, then a workaround is to change the source of the calling code to check for java.lang.management.PlatformLoggingMXBean instead.

  2. The Logging MXBean MBeanInfo will now report that its management interface is java.lang.management.PlatformLoggingMXBean instead of the non standard sun.management.ManagementFactoryHelper$LoggingMXBean name it used to display.

    The new behavior has the advantage that the reported interface name is now a standard class.

  3. Local clients which obtain an instance of the logging MXBean by calling ManagementFactory.getPlatformMXBean(PlatformLoggingMXBean.class) will no longer be able to cast the result to java.util.logging.LoggingMXBean.

    PlatformLoggingMXBean already has all the methods defined in LoggingMXBean, therefore a simple workaround is to change the code to accept PlatformLoggingMXBean instead - or change it to use the deprecated LogManager.getLoggingMXBean() instead.

See JDK-8139982






Since build 117  Integrations

core-libs/java.rmi

Remove HTTP proxying from RMI

The mechanism of proxying RMI requests through HTTP, which was deprecated in Java SE 8, has been removed in Java SE 9. This mechanism used a web CGI script called java-rmi.cgi. This script has also been removed. The default mechanism for transmitting RMI requests is now simply a direct socket connection.

See JDK-8066750






Since build 116  Integrations

deploy

Deployment Tookit API methods no longer installs JRE

The Deployment Toolkit API installLatestJRE() and installJRE(requestedVersion) methods from deployJava.js and install() method from dtjava.js no longer installs the JRE. If a user's version of Java is below the security baseline, it redirects the user to java.com to get an updated JRE.

JDK-8148310 (not public)






Since build 115  Integrations

security-libs/javax.crypto

Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits

Extend to support 3072-bits DH and DSA parameters generation, and pre-computed DH parameters up to 8192 bits and pre-computed DSA parameters up to 3072-bits.

See JDK-8072452






Since build 114  Integrations

hotspot/compiler

Remove obsolete Unsafe.putOrdered{X} methods

The putOrderedObject, putOrderedInt and putOrderedLong methods have been removed from jdk.internal.misc.Unsafe because they became obsolete with the introduction of VarHandles. Their uses have been replaced by putObjectRelease, putIntRelease and putLongRelease from jdk.internal.misc.Unsafe.

See JDK-8152698






core-libs/java.net

Remove the JDK-Internal name service provider interface and default implementation

Previous JDK releases documented how to configure java.net.InetAddress to use the JNDI DNS service provider as the name service. This mechanism, and the system properties to configure it, have been removed in JDK 9

A new mechanism to configure the use of a hosts file has been introduced.

A new system property jdk.net.hosts.file has been defined. When this system property is set, the name and address resolution calls of InetAddress, i.e getByXXX, retrieve the relevant mapping from the specified file. The structure of this file is equivalent to that of the /etc/hosts file.

When the system property jdk.net.hosts.file is set, and the specified file doesn't exist, the name or address lookup will result in an UnknownHostException. Thus, a non existent hosts file is handled as if the file is empty.

See JDK-8134577






Since build 112  Integrations

core-libs

Support system or alternative implementations of zlib

The Java runtime now uses system zlib library (the zlib library installed on the underlying operation system) for its zlib compression support (the deflation and inflation functionality in java.util.zip, for example) on Solaris and Linux platforms.

See JDK-8031767






javafx/media

VP6 video and FXM/FLV container are deprecated

Support for VP6 video encoding format and FXM/FLV container are deprecated in JavaFX Media and it will be removed in a future release. Users encouraged to use H.264/AVC1 in MP4 container or HTTP Live Streaming instead.

See JDK-8134330






Since build 110  Integrations

other-libs

Removal of com.apple.concurrent.Dispatch

The com.apple.concurrent.Dispatch API was a Mac-only API and was carried into JDK 7u4 with the port of Apple's JDK 6 code. This seldom-used and unsupported API will be removed from JDK 9. The standard java.util.concurrent.Executor and java.util.concurrent.ExecutorService implementations remain available for use.

See JDK-8148187






hotspot/runtime

Update JNI Version Number

The current version of the Java Native Interface (JNI) needs to be updated due to the addition of new application programmatic interfaces to support Jigsaw. JNI_VERSION_9 was added with a value of 0x00090000 to the available versions and CurrentVersion was changed to this new value.

See JDK-8145098






hotspot/svc

Binary format for HPROF updated

When dumping the heap in binary format, HPROF format 1.0.2 is always used now. Previously format 1.0.1 was used for heaps smaller than 2GB. HPROF format 1.0.2 is also used by jhsdb jmap for the serviceability agent.

See JDK-8144732






Since build 109  Integrations

security-libs/java.security

Default key sizes for the AlgorithmParameterGenerator and KeyPairGenerator implementations updated

To improve security, the default key size for the RSA and DiffieHellman KeyPairGenerator implementations and the DiffieHellman AlgorithmParameterGenerator implementations has been increased from 1024 bits to 2048 bits. The default key size for the DSA KeyPairGenerator and AlgorithmParameterGenerator implementations remains at 1024 bits to preserve compatibility with applications that are using keys of that size with the SHA1withDSA signature algorithm.

With increases in computing power and advances in cryptography, the minimum recommended key size increases over time. Therefore, future versions of the platform may increase the default size.

See JDK-8138653






core-libs/jdk.nashorn

CodeStore service has been removed

The possibility to provide provide subclasses of jdk.nashorn.internal.runtime.CodeStore through the java.util.ServiceLoader API has been removed in JDK 9.

See JDK-8148148






security-libs/javax.net.ssl

Restrict Diffie-Hellman keys less than 1024 bits

Diffie-Hellman keys less than 1024 bits are considered too weak to use in practice and should be restricted by default in SSL/TLS/DTLS connections. Accordingly, Diffie-Hellman keys less than 1024 bits have been disabled by default by adding "DH keySize < 1024" to the "jdk.tls.disabledAlgorithms" security property in the java.security file. Although it is not recommended, administrators can update the security property ("jdk.tls.disabledAlgorithms") and permit smaller key sizes (for example, by setting "DH keySize < 768").

JDK-8148108 (not public)






Since build 107  Integrations

tools/javadoc(tool)

Omit public and abstract modifiers in javadoc for annotation type members

Previously javadoc would emit "public" and "abstract" modifiers for methods and fields in annotation types. These flags are not needed in source code and are elided for non-annotation interface types. With this change, those modifiers are also omitted for methods and fields defined in annotation types.

See JDK-6469561






tools/javadoc(tool)

Compact javadoc display of single-element annotations

Previously javadoc would include "value=" when displaying annotations even when that text was not necessary in the source because the annotations were of single-element annotation type (JLS 9.6. Annotation Type Elements ). The extraneous "value=" text is now omitted, leading to more concise annotation display.

See JDK-6469562






Since build 105  Integrations

client-libs/java.awt

AppletViewer is deprecated

The AppletViewer tool was deprecated as a part of "JEP C161: Deprecate the Java Plug-in", and its use isn't recommended,

More information about AppletViewer: http://docs.oracle.com/javase/8/docs/technotes/tools/windows/appletviewer.html

JDK-8074165 (not public)






Since build 104  Integrations

security-libs/java.security

Deprecate policytool

The policytool security tool is moved into the jdk.policytool module and has been deprecated.

See JDK-8147400






core-libs/java.nio

Ability to limit the capacity of buffers that can be held in the temporary buffer cache

The system property jdk.nio.maxCachedBufferSize has been introduced in 9 to limit the memory used by the "temporary buffer cache". The temporary buffer cache is a per-thread cache of direct memory used by the NIO implementation to support applications that do I/O with buffers backed by arrays in the java heap. The value of the property is the maximum capacity of a direct buffer that can be cached. If the property is not set then no limit is put on the size of buffers that are cached. Applications with certain patterns of I/O usage may benefit from using this property. In particular if an application does I/O with large multi-megabyte buffers at startup but therefore does I/O with small buffers may see a benefit to using this property. Applications that do I/O using direct buffers will not see any benefit to using this system property.

See JDK-8147468






Since build 103  Integrations

core-libs/java.lang

Phantom references are automatically cleared as soft and weak references

This enhancement changes phantom references to be automatically cleared by the garbage collector as soft and weak references.

An object becomes phantom reachable after it has been finalized. This change may cause the phantom reachable objects to be GC'ed earlier - previously the referent is kept alive until PhantomReference objects are GC'ed. This potential behavioral change might only impact existing code that would depend on PhantomReference being enqueued rather than when the referent be freed from the heap.

See JDK-8071507






hotspot/gc

Use Unified Logging for the GC logging

The logging for all garbage collectors in HotSpot have been changed to make use of a new logging framework that is configured through the -Xlog command line option. The command line flags -XX:+PrintGC, -XX:+PrintGCDetails and -Xloggc have been deprecated and will likely be removed in a future release. They are currently mapped to similar -Xlog configurations. All other flags that were used to control garbage collection logging have been removed. See the documentation for -Xlog for details on how to now configure and control the logging. These are the flags that were removed:

CMSDumpAtPromotionFailure, CMSPrintEdenSurvivorChunks, G1LogLevel, G1PrintHeapRegions, G1PrintRegionLivenessInfo, G1SummarizeConcMark, G1SummarizeRSetStats, G1TraceConcRefinement, G1TraceEagerReclaimHumongousObjects, G1TraceStringSymbolTableScrubbing, GCLogFileSize, NumberOfGCLogFiles, PrintAdaptiveSizePolicy, PrintClassHistogramAfterFullGC, PrintClassHistogramBeforeFullGC, PrintCMSInitiationStatistics, PrintCMSStatistics, PrintFLSCensus, PrintFLSStatistics, PrintGCApplicationConcurrentTime, PrintGCApplicationStoppedTime, PrintGCCause, PrintGCDateStamps, PrintGCID, PrintGCTaskTimeStamps, PrintGCTimeStamps, PrintHeapAtGC, PrintHeapAtGCExtended, PrintJNIGCStalls, PrintOldPLAB, PrintParallelOldGCPhaseTimes, PrintPLAB, PrintPromotionFailure, PrintReferenceGC, PrintStringDeduplicationStatistics, PrintTaskqueue, PrintTenuringDistribution, PrintTerminationStats, PrintTLAB, TraceDynamicGCThreads, TraceMetadataHumongousAllocation, UseGCLogFileRotation, VerifySilently

See JDK-8145092






hotspot/compiler

Remove Use486InstrsOnly flag

The -XX:+Use486InstrsOnly flag has been removed because it is no longer supported.

See JDK-6808665






Since build 102  Integrations

core-libs

Removed stopThread RuntimePermission from the default java.policy

The default java.policy no longer grants stopThread runtime permission in JDK 9.

In previous releases, untrusted code had the stopThread runtime permission by default. This allows untrusted code to call Thread::stop ( on threads other than the current one ). Having an arbitrary exception thrown asynchronously is not something that trusted code should be expected to handle gracefully. So this permission is removed by default in JDK 9. The following line is deleted from the file conf/security/java.policy : permission java.lang.RuntimePermission "stopThread";

See JDK-7067728






Since build 101  Integrations

other-libs/other

The jdk.Exported annotation has been removed

The JDK-specific annotation @jdk.Exported has been removed in JDK 9. The information that @jdk.Exported conveyed is now recorded in the exports declarations of modules. Tools that scan for this annotations should be updated to make use of the new API support in javax.lang.model andjava.lang.module.

See JDK-8049422






Since build 99  Integrations

core-libs/java.util:collections

Collections.asLifoQueue(null) now throws NPE as specified

Before the JDK 9 release, invocation of the method Collections.asLifoQueue with a null argument value would not throw a NullPointerException as specified by the class documentation. Instead a NullPointerException would be thrown when operating on the returned Queue. The JDK 9 release corrects the implementation of Collections.asLifoQueue to conform to the specification. Behavioral compatibility is not preserved but it is expected that the impact will be minimal given analysis of existing usages.

See JDK-8145006






core-libs/java.nio

CharArrayReader, PushbackReader, and StringReader may now block in close()

The java.io classes CharArrayReader, PushbackReader, and StringReader might now block in close() if there is another thread holding the Reader.lock lock.

The read() method of these classes could previously throw a NullPointerException if the internal state of the instance had become inconsistent. This was caused by a race condition due to close() not obtaining a lock before modifying the internal state of the Reader. This lock is now obtained which can result in close() blocking if another thread simultaneously holds the same lock on the Reader.

See JDK-8143394






Since build 97  Integrations

deploy

Apple script engine has been removed

Apple script engine implementing javax.script engine API has been removed without replacement. The AppleScript engine has worked inconsistently. The services configuration (META-INF/services) file was missing and only worked by accident when installing JDK 7 or JDK 8 on systems that had Apple's version of AppleScriptEngine.jar already on the system.

See JDK-8143404






core-libs/java.util.jar

The system property sun.zip.disableMemoryMapping has been removed

The zip library implementation has been improved in JDK 9. The new java.util.zip.ZipFile implementation does not use mmap to map ZIP file central directory into memory anymore. As a result, the sun.zip.disableMemoryMapping system property is no longer needed and has been removed.

See JDK-8142508






Since build 96  Integrations

core-libs/java.nio

sun.nio.sh.PollSelectorProvider removed

Superior SelectorProvider implementations exist for all Oracle JDK platforms and PollSelectorProvider should not be used on those platforms if at all possible. That being the case we're removing it from the build on all Oracle supported platforms while leaving the source in the repo for reference purposes.

See JDK-8142872






deploy/plugin

Deprecation of common DOM APIs

The com.sun.java.browser.plugin2.DOM, and sun.plugin.dom.DOMObject APIs have been deprecated and will be removed in a future release of Java. Applications can use netscape.javascript.JSObject to manipulate the DOM.

JDK-8074162 (not public)






Since build 94  Integrations

security-libs/jdk.security

New APIs for jar signing

A new jdk.security.jarsigner.JarSigner API is added to the jdk.jartool module which can be used to sign a jar file.

See JDK-8056174






hotspot/runtime

JNIDetachReleasesMonitors is obsolete

The -XX:-JNIDetachReleasesMonitors flag requested that the VM run in a pre-JDK 6 compatibility mode with regard to not releasing monitors when a JNI attached thread detaches. This option is obsolete in JDK 9, and is ignored, as the VM always conforms to the JNI Specification and releases monitors. Use of this option will result in a warning being issued in JDK 9 and it may be removed completely in a future release.

See JDK-8131045






Since build 92  Integrations

deploy

ability to double-jar class files deprecated

The ability to double-jar (jarjar) a set of class files in Java deployment technologies has been deprecated. The following warning will be issued if a jarjar file is downloaded:

"WARNING: A jarjar file has been loaded. Jarjar files are deprecated and will be removed in a future Java release. This application may not function properly in the future. Jarjar file URL: {URL}"

JDK-8074157 (not public)






xml/jaxp

XML Catalog API

Java SE 9 introduces a standard XML Catalog API that supports the OASIS XML Catalogs version 1.1 standard. The API defines catalog and catalog-resolver abstractions that can be used as an intrinsic or external resolver with the JAXP processors that accept resolvers.

Existing libraries or applications that use the internal catalog API shall consider migrating to the new API in order to take advantage of the new features.

See JDK-8081248






core-svc/javax.management

Define ConstructorParameters annotation type for MXBeans

A new annotation @javax.management.ConstructorParameters in the java.management module is introduced.

The newly introduced annotation will be 1:1 copy of @java.beans.ConstructorProperties. Constructors annotated by @java.beans.ConstructorProperties will still be recognized and processed.

In case a constructor is annotated by both @javax.management.ConstructorParameters and @java.beans.ConstructorProperties only the @javax.management.ConstructorParameters will be used.

See JDK-8139727






Since build 89  Integrations

core-libs/java.lang

Unicode 8 support

The JDK 9 release includes support for Unicode 8.0. Since the release of JDK 8, which supported Unicode 6.2.0, the Unicode 8.0 introduced the following new features that are now included in JDK 9:

See JDK-8072600






hotspot/compiler

Remove per-compiler performance counters

Per-thread compiler performance counters have been removed because they became obsolete in the presence of more fine-grained and precise compilation events. The corresponding interface in sun.management.* has been deprecated since it will no longer provide information without the performance counters. Users can get similar or more fine-grained information via global performance counters, the event tracing API (JFR) or -XX:+PrintCompilation.

See JDK-8134607






xml/jaxp

A new property "maxXMLNameLimit" is added

A new property "maxXMLNameLimit" is added to limit the maximum size of XML names, including element name, attribute name and namespace prefix and URI. It is recommended that users set the limit to the smallest possible number so that malformed XML files can be caught quickly. For more about XML processing limits, please see The Java Tutorials, Processing Limits.

JDK-8086733 (not public)






client-libs/java.awt

Some platforms may not support showing the user-specified title in a file dialog.

There are some platforms like Mac OS X 10.11 that may not support showing the user-specified title in a file dialog.

The following description is added to the to the java.awt.FileDialog class constructors and setTitle(String) method: "Note: Some platforms may not support showing the user-specified title in a file dialog. In this situation, either no title will be displayed in the file dialog's title bar or, on some systems, the file dialog's title bar will not be displayed".

JDK-8138674 (not public)






Since build 85  Integrations

core-libs/java.util:i18n

SPI based locale sensitive services need to be explicitly specified

The default locale data provider lookup does not load SPI based locale sensitive services. If it is needed, the system property "java.locale.providers" needs to designate "SPI" explicitly. For more detail, refer to LocaleServiceProvider.

See JDK-8138613






Since build 83  Integrations

security-libs/java.security

Required Algorithms for JDK 9

The following have been added to the security algorithm requirements for JDK implementations (keysize in parentheses):

  1. Signature: SHA256withDSA
  2. KeyPairGenerator: DSA (2048), DiffieHellman (2048, 4096), RSA (4096)
  3. AlgorithmParameterGenerator: DSA (2048), DiffieHellman (2048)
  4. Cipher: AES/GCM/NoPadding (128), AES/GCM/PKCS5Padding (128)
  5. SSLContext: TLSv1.1, TLSv1.2
  6. TrustManagerFactory: PKIX
See JDK-8015388






core-svc/javax.management

Support for IIOP transport from JMX RMI connector is removed.

IIOP transport from JMX RMIConnector has been removed. RMI is now the only supported JSR160 connector.

JDK-8043937 (not public)






Since build 81  Integrations

core-svc/javax.management

JMX ObjectName optimized to reduce memory footprint

JMX ObjectName class is refactored and 8 bytes of class member metadata was reduced.

Each instance size of JMX ObjectName in memory is 8 bytes less than JDK8 ObjectName instance.

A new restriction on domain name length is introduced. The domain name now is a case sensitive string of limited length. The domain name length limit is Integer.MAX_VALUE/4.

JDK-8041565 (not public)






hotspot/compiler

Interpreter and compiled code process signaling NaN values inconsistently in 32-bit x86 VM

The IEEE 754 standard distinguishes between signaling and quiet NaNs. When executing floating point operations, some processors silently convert signaling NaNs to quiet NaNs. The 32-bit x86 version of the HotSpot JVM allows silent conversions to happen. With JVM releases preceding JDK 9, silent conversions happen depending on whether the floating point operations are part of compiled or interpreted code. With the JDK 9 release, interpreted and compiled code behaves consistently with respect to signaling and quiet NaNs.

See JDK-8076373






Since build 80  Integrations

client-libs

Restrict javax.imageio.spi.ServiceRegistry to ImageIO types

Since Java SE 1.4 javax.imageio.spi.ServiceRegistry provided a facility roughly equivalent to the Java SE 1.6 java.util.ServiceLoader. This image i/o facility is now restricted to supporting SPIs defined as part of javax.imageio. Applications which use it for other purposes need to be re-coded to use ServiceLoader.

See JDK-8068749






tools/launcher

Support @-files for java command-line tool

The java launcher now supports reading arguments from "argument files" specified on the command line. It is not uncommon that the java launcher is invoked with very long command lines (a long class path for example). Many operating systems impose a limit on the length of a command line, something that "argument files" can be used to work around.

In JDK 9, java now can read arguments from specified files as they are put on the command line. See java command reference and java Command-Line Argument Files for more details.

See JDK-8027634






Since build 76  Integrations

core-libs/java.util:i18n

UTF-8 based Properties Files

Properties files in UTF-8 encoding are now supported by ResourceBundle, with automatic fall back to ISO-8859-1 encoding if needed. For more detail, refer to PropertiyResourceBundle class description.

See JDK-8027607






Since build 74  Integrations

hotspot/runtime

VM Options "-Xoss", "-Xsqnopause", "-Xoptimize" and "-Xboundthreads" are obsolete

The VM Options "-Xoss", "-Xsqnopause", "-Xoptimize" and "-Xboundthreads" are obsolete in JDK 9 and are ignored. Use of these options will result in a warning being issued in JDK 9 and they may be removed completely in a future release.

The VM Options "-Xoss", "-Xsqnopause", "-Xoptimize" options were already silently ignored for a long time.

The VM Option "-Xboundthreads" was only needed on Solaris 8/9 (when using the T1 threading library).

See JDK-8078399






Since build 73  Integrations

core-libs/java.util:collections

Arrays.asList().toArray() returns Object[]

The Arrays.asList() API returns an instance of List. Calling the toArray() method on that List instance is specified always to return Object[], that is, an array of Object. In previous releases, it would sometimes return an array of some subtype. Note that the declared return type of Collection.toArray() is Object[], which permits an instance of an array of a subtype to be returned. The specification wording, however, clearly requires an array of Object to be returned.

The toArray() method has been changed to conform to the specification, and it now always returns Object[]. This may cause code that was expecting the old behavior to fail with a ClassCastException. An example of code that worked in previous releases but that now fails is the following:

    List<String> list = Arrays.asList("a", "b", "c");
    String[] array = (String[]) list.toArray();

If this problem occurs, rewrite the code to use the one-arg form toArray(T[]), and provide an instance of the desired array type. This will also eliminate the need for a cast.

    String[] array = list.toArray(new String[0]);
See JDK-6260652






Since build 71  Integrations

core-libs/java.util:i18n

Use CLDR locale data by default

The default locale data has been switched to use data derived from the Unicode Consortium's Common Locale Data Repository (CLDR). For more detail, refer to the JEP 252.

See JDK-8008577






Since build 69  Integrations

security-libs/java.security

Deprecate the com.sun.jarsigner package

The com.sun.jarsigner package is now deprecated. This includes the ContentSigner class, the ContentSignerParameters interface, and the jarsigner command's "-altsigner" and "-altsignerpath" options.

See JDK-8076535






Since build 68  Integrations

client-libs/2d

Value of java.awt.font.OpenType.TAG_OPBD is incorrect

The value of the static final int field java.awt.font.OpenType.TAG_OPBD was incorrect

It was erroneously using the same value as TAG_MORT 0x6D6F7274UL and it has been changed to the correct 0x6F706264UL

Although this is strictly an incompatible binary change the likelihood of any practical impact on applications is near zero. The opbd table is used only in AAT fonts: https://developer.apple.com/fonts/TrueType-Reference-Manual/RM06/Chap6opbd.html and as such is likely to be extremely rare in the wild as they are natively understood only by MacOS and iOS. This table is not critical to rendering of text by Java or anything else. As such nothing goes looking for the table and nothing inside JDK utilises any part of this class.

Nor does the JDK provide anyway at all to utilise these values directly - no Java API exists that accepts them. The class will not become useful without additional Java API that has not been added to date.

Even if an application were to use it by passing the Java field's value to some custom native code to look up a table then it is likely to return "null" both before and afterward since

  1. the opbd table is extremely rare.
  2. the "mort" table that the old value located is already replaced in all fonts on OSX by the "morx" table.

A representative sampling of 6 OS X fonts found none of them to have either table

See JDK-8077584






Since build 67  Integrations

tools

Removal of native2ascii tool

native2ascii tool is removed in JDK 9. JDK 9 supports UTF-8 based properties resource bundles (see JEP 226) and the conversion for UTF-8 based properties resource bundles to ISO-8859-1 is no longer needed.

See JDK-8074431






Since build 65  Integrations

security-libs/java.security

Custom Policy Providers may need additional configuration

Classes loaded from the extensions directory are no longer granted AllPermission by default. See JDK-8040059.

A custom java.security.Policy provider that was using the extensions mechanism may be depending on the policy grant statement that had previously granted it AllPermission. If the policy provider does anything that requires a permission check, the local policy file may need to be adjusted to grant those permissions.

Also, custom policy providers are loaded by the system class loader. The classpath may need to be configured to allow the provider to be located.

See JDK-8075706






client-libs

References to java.awt.peer and java.awt.dnd.peer packages were removed from the public API

All methods that refer to types defined in the java.awt.peer and java.awt.dnd.peer packages (the "peer types") were removed from the Java API in Java SE 9 . Application code which calls any such method which accepts or returns a type defined in these packages will no longer link. This is a BINARY incompatible change.

An additional information is provided here: http://mail.openjdk.java.net/pipermail/awt-dev/2015-February/008924.html

See JDK-8037739






Since build 64  Integrations

core-svc/javax.management

New ManagementAgent.status diagnostic command added.

A new ManagementAgent.status diagnostic command is introduced for querying the JMX agent's status.

The status will be relayed to the user in the following form:

Agent: <enabled|disabled>
(
  ConnectionType: <local|remote>
  Protocol: <rmi|...>
  Host: <IP or host name>
  URL: <valid JMX connector URL>
  (
    Properties:
    (
      <propertyname>=<propertyvalue>
    )+
  )?
)+

Where:
  <name>    means an arbitrary value
  |         means 'or'
  ( and )   denote a block
  +         block repeats one or more times
  ?         block appears at most once
See JDK-8023093






core-libs/java.nio

The SecurityException throws clauses of the java.nio.file.Files methods newBufferedWriter() and write() now indicate that the exception might arise from a "delete" permission check

The sentence

"The {@link SecurityManager#checkDelete(String) checkDelete} method is invoked to check delete access if the file is opened with the {@code DELETE_ON_CLOSE} option."

was appended to the verbiage of the SecurityException throws clause in the specifications of the newBufferedWriter() and write() methods of java.nio.file.Files.

See JDK-8065109






core-svc/java.lang.management

com.sun.management package is part of jdk.management module

New module jdk.management is created which contains com.sun.management and com.sun.management.internal packages.

Platform MBean which were solely defined in com.sun.management (e.g. HotspotDiagnosticMXBean) are moved to com.sun.management.internal in the jdk.management module.

Platform MBean which were defined in java.lang.management package and also had a com.sun.management extension (e.g. OperatingSystemMXBean) now have two concrete implementation classes: one in java.management module and one in jdk.management module. Which one is selected depend's on whether jdk.management is present or not in the image.

See JDK-8042901






core-libs/java.lang.invoke

Class.getSimpleName() reads from the InnerClasses attribute

Class.getSimpleName() was changed to use the name recorded in the InnerClasses attribute of the class file. This change may affect applications which generate custom bytecode with incomplete or incorrect information recorded in the InnerClasses attribute.

See JDK-8057919






Since build 63  Integrations

core-libs/java.util

java.util.prefs.Preferences now disallows the use of any String containing the null control character

The specification of the class java.util.prefs.Preferences was modified to disallow the use of any String containing the null control character, code point U+0000, in any String used as the key or value parameter in any of the abstract put*(), get*(), and remove methods. If such a character is detected, an IllegalArgumentException shall be thrown.

The specification of the class java.util.prefs.AbstractPreferences was modified according to the corresponding change in its superclass java.util.prefs.Preferences to disallow the use of any String containing the null control character, code point U+0000, in any String used as the key or value parameter in any of the put*(), get*(), and remove() method implementations. These method implementations were modified to throw an IllegalArgumentException upon encountering such a character in a key or value String in these contexts. Also, the class specification was modified to correct the erroneous reference to the flush() and sync() methods as returning a boolean value when they are in fact void.

See JDK-8075156






Since build 62  Integrations

tools/javac

several incorporation steps are silently failing when an error should be reported

Reporting previously silent errors found during incorporation, JLS 8 §18.3, was supposed to be a clean-up with performance only implications. But consider the test case:

import java.util.Arrays;
import java.util.List;

class Klass {
    public static <A> List<List<A>> foo(List<? extends A>... lists) {
        return foo(Arrays.asList(lists));
    }

    public static <B> List<List<B>> foo(List<? extends List<? extends B>> lists) {
        return null;
    }
}

This code was not accepted before the patch for [1], but after this patch the compiler is accepting it. Accepting this code is the right behavior as not reporting incorporation errors was a bug in the compiler.

While determining the applicability of method:

<B> List<List<B>> foo(List<? extends List<? extends B>> lists)

For which we have the constraints:

b <: Object
t <: List<? extends B>
t<: Object
List<? extends A> <: t

First, inference variable b is selected for instantiation:

b = CAP1 of ? extends A

so this implies that:

t <: List<? extends CAP1 of ? extends A>
t<: Object
List<? extends A> <: t

Now all the bounds are checked for consistency. While checking if List<? extends A> is a subtype of List<? extends CAP1 of ? extends A> a bound error is reported. Before the compiler was just swallowing it. As now the error is reported while inference variable b is being instantiated, the bound set is rolled back to it's initial state, 'b' is instantiated to Object, and with this instantiation the constraint set is solvable, the method is applicable, it's the only applicable one and the code is accepted as correct. The compiler behavior in this case is defined at JLS 8 §18.4

This fix has source compatibility impact, right now code that wasn't being accepted is now being accepted by the javac compiler. Currently there are no reports of any other kind of incompatibility.

[1] [https://bugs.openjdk.java.net/browse/JDK-8078024](https://bugs.openjdk.java.net/browse/JDK-8078024)

See JDK-8078024






Since build 61  Integrations

xml/jaxp

Non Java SE DOM APIs moved to jdk.xml.dom module

Before the Java SE 9 release, the DOM API package in org.w3c.dom included sub-packages that were not defined as a part of the Jave SE API. As of Java SE 9, these sub-packages are moved out of the java.xml module to a separate module called jdk.xml.dom. These packages are as follows:

    org.w3c.dom.css
    org.w3c.dom.html
    org.w3c.dom.stylesheets
    org.w3c.dom.xpath
See JDK-8042244






Since build 60  Integrations

security-libs/javax.security

auth.login.LoginContext needs to be updated to work with modules

After this change, besides implementing the necessary methods (initialize, login, logout, commit, abort), any login module must implement the LoginModule interface. Otherwise a LoginException will be thrown when the login module is used.

See JDK-8047789






Since build 59  Integrations

core-libs/java.util.logging

LogManager.readConfiguration will no longer propagate IllegalArgumentException directly when the logging configuration property file contains invalid unicode escape sequences.

LogManager.readConfiguration calls Properties.load, which may throw IllegalArgumentException if it encounters an invalid unicode escape sequence in the input stream. In previous versions of the JDK, the IllegalArgumentException was simply propagated to the caller. This was however in violation of the specification, since LogManager.readConfiguration is not specified to throw IllegalArgumentException. Instead, it is specified to throw IOException ''if there are problems reading from the stream''. In Java SE 9, LogManager.readConfiguration will no longer propagate such IllegalArgumentException directly, but will wrap it inside an IOException in order to conform to the specification.

See JDK-8075810






Since build 56  Integrations

hotspot/runtime

VM Options AdaptiveSizePausePolicy and ParallelGCRetainPLAB are obsolete

The VM Options -XX:AdaptiveSizePausePolicy and -XX:ParallelGCRetainPLAB are obsolete in JDK 9 and are ignored. Use of these options will result in a warning being issued in JDK 9 and they may be removed completely in a future release.

The VM Option -XX:AdaptiveSizePausePolicy has been unused for some time.

The VM Option -XX:ParallelGCRetainPLAB was a diagnostic flag relating to garbage collector combinations that no longer exist.

See JDK-8073861






hotspot/runtime

VM Options AdjustConcurrency and PrintJVMWarnings are removed

The VM Options -XX:AdjustConcurrency and -XX:PrintJVMWarnings are removed from JDK 9.

The VM option -XX:AdjustConcurrency was only needed on Solaris 8/9 (when using the T1 threading library).

The VM option -XX:PrintJVMWarnings was a development option only used by unimplemented VM functions that have themselves been removed in JDK 9.

See JDK-8073861






client-libs/javax.swing

JFrame.EXIT_ON_CLOSE was removed in favour of WindowConstants.EXIT_ON_CLOSE

The public static constant JFrame.EXIT_ON_CLOSE was removed in favour of WindowConstants.EXIT_ON_CLOSE.

See JDK-8073420






Since build 55  Integrations

security-libs/java.security

Deprecate security APIs that have been superseded

The classes and interfaces in the java.security.acl and javax.security.cert packages have been superseded by replacements for a long time and are deprecated in JDK 9. Two methods javax.net.ssl.HandshakeCompletedEvent.getPeerCertificateChain() and javax.net.ssl.SSLSession.getPeerCertificateChain() are also deprecated since they return the javax.security.cert.X509Certificate type.

See JDK-8073430






Since build 53  Integrations

core-libs/java.util.logging

Precision of time stamps in java.util.logging.LogRecord has been increased

LogRecord now stores the event time in the form of a java.time.Instant. XMLFormatter DTD is upgraded to print the new higher time resolution.

In Java SE 9 java.util.logging is updated to use java.time instead of System.currentTimeMillis() and java.util.Date. This allows for higher time stamp precision in LogRecord.

As a consequence, the implementation of the methods getMillis() and setMillis(long) in java.util.logging.LogRecord has been changed to use java.lang.Instant, and the method setMillis(long) has been deprecated in favor of the new method LogRecord.setInstant(java.time.Instant). The java.util.logging.SimpleFormatter has been updated to pass a java.time.ZonedDateTime object instead of java.util.Date to String.format. The java.util.logging.XMLFormatter has been updated to print a new optional <nanos> XML element after the <millis> element. The <nanos> element contains a nano seconds adjustment to the number of milliseconds printed in the <millis> element. The XMLFormatter will also print the full java.time.Instant in the <date> field, using the java.time.format.DateTimeFormatter.ISO_INSTANT formatter.

Compatibility with previous releases:

The LogRecord serial form, while remaining fully backward/forward compatible, now contains an additional serial nanoAdjustment field of type int, which corresponds to a nano seconds adjustment to the number of milliseconds contained in the serial millis field. If a LogRecord is serialized and transmitted to an application running on a previous release of the JDK, the application will simply see a LogRecord with a time truncated at the millisecond resolution. Similarly, if a LogRecord serialized by an application running on a previous release of the JDK, is transmitted to an application running on Jva SE 9 or later, only the millisecond resolution will be available.

Applications that parse logs produced by the XMLFormatter, and which perform validation, may need to be upgraded with the newer version of the logger.dtd, available in the appendix A of the Logging Overview. In order to mitigate the compatibilty risks, the XMLFormatter class (and subclasses) can be configured to revert to the old XML format from Java SE 8 and before. See the java.util.logging.XMLFormatter API documentation for more details.

There could also be an issue if a subclass of LogRecord overrides getMillis/setMillis without calling the implementation of the super class. In that case, the event time as seen by the formatters and other classes may be wrong, as these have been updated to no longer call getMillis() but use getInstant() instead.

See JDK-8072645






core-libs/java.nio.charsets

IBM1166 character set now available

This release adds IBM1166 character set. It provides support for cyrillic multilingual with euro for Kazakhstan. Aliases for this new character set include "cp1166","ibm1166", "ibm-1166", "1166".

See JDK-8071447






tools/javac

Changes in the way javac handles wildcards and capture type variables

The javac compiler's behavior when handling wildcards and "capture" type variables has been improved for conformance to the language specification. This improves type checking behavior in certain unusual circumstances. It is also a source-incompatible change: certain uses of wildcards that have compiled in the past may fail to compile because of a program's reliance on the javac bug.

See JDK-8039214






Since build 52  Integrations

security-libs

Add variant of DSA Signature algorithms that do not ASN.1 encode the signature bytes

A non-ASN.1 encoded form for DSA and ECDSA signatures has been implemented. This new signature output format concatenates the r and s values from the signature in conformance with IEEE P1363. Signature objects using this format must provide one of the following algorithm Strings to the Signature.getInstance() method:

For DSA: NONEwithDSAinP1363Format SHA1withDSAinP1363Format SHA224withDSAinP1363Format SHA256withDSAinP1363Format

For ECDSA: NONEwithECDSAinP1363Format SHA1withECDSAinP1363Format SHA224withECDSAinP1363Format SHA256withECDSAinP1363Format SHA384withECDSAinP1363Format SHA512withECDSAinP1363Format

See JDK-8042967






core-svc

com.sun.tracing APIs are removed

The following unsupported APIs are removed:

See JDK-8062303






Since build 51  Integrations

xml/jax-ws

JAX-WS, JAXB, JAF are deprivileged and defined by platform class loader

The defining class loader of java.xml.ws, java.xml.bind, and java.activation module and their classes is changed to the platform class loader (non-null) (see the specification for java.lang.ClassLoader::getPlatformClassLoader). In addition, they are de-privileged and granted with specific permissions.

Existing code that assumes the defining class loader of JAX-WS, JAXB, JAF classes may be impacted by this change (e.g. custom class loader delegation to the bootstrap class loader skipping the extension class loader). They are standalone technologies that used to be loaded by non-null class loader before they were included in Java SE. It should be rare of such dependency.

Callbacks may assume java.xml.ws and java.xml.bind classes to have AllPermission so that when running with security manager, if the permission required for callback is not part of the permission set granted to java.xml.ws and java.xml.bind, SecurityException will be thrown. This may happen when the user-defined callback is missing AccessController::doPrivileged.

The proper fix is to modify the existing code to ensure use of AccessController::doPrivileged wrapping privileged calls.

An interim solution is to modify the security policy to grant AllPermission for example: grant codeBase "jrt:/java.xml.ws" { permission java.security.AllPermission; };

See JDK-8057645






javafx/scenegraph

JavaFX builder classes have been removed

The JavaFX builder classes, which were previously deprecated in JDK 8 with the stated intention to remove them, have been removed from JDK 9. JavaFX applications that use the builder classes should instead construct the needed scene graph objects directly and set the desired properties with the equivalent method calls.

See JDK-8092861






Since build 50  Integrations

core-libs/java.time

The implementation of the clock returned by system factory methods in java.time.Clock has increased the resolution

The Java SE 8 specification for java.time.Clock states that ''The system factory methods provide clocks based on the best available system clock. This may use System.currentTimeMillis(), or a higher resolution clock if one is available.'' In JDK 8 the implementation of the clock returned was based on System.currentTimeMillis(), and thus has only a millisecond resolution. In JDK 9, the implementation is based on the underlying native clock that System.currentTimeMillis() is using, providing the maximum resolution available from that clock. On most systems this can be microseconds, or sometimes even tenth of microseconds.

An application making the assumption that the clock returned by these system factory methods will always have milliseconds precision and actively depends on it, may therefore need to be updated in order to take into account the possibility of a greater resolution, as was stated in the API documentation. It is also worth noting that a new Clock.tickMillis(zoneId) method has been added to allow time to be obtained at only millisecond precision - see: http://download.java.net/java/jdk9/docs/api/java/time/Clock.html#tickMillis-java.time.ZoneId-.

See JDK-8068730






core-libs/java.nio

java.nio.channels.FileLock constructors don't throw NPE if the channel argument is null

The java.nio.channels.FileLock constructors will now throw a NullPointerException if called with a null Channel parameter. To avoid an unexpected behavior change, subclasses of FileLock should therefore ensure that the Channel they pass to the superclass constructor is non-null.

See JDK-6880737






Since build 49  Integrations

xml/javax.xml.xpath

XPath enhancement

Java SE 9 improves the javax.xml.xpath API with new APIs that make use of modern language features to facilitate ease of use and extend support of the XPath specification.

  1. Support ANY type

javax.xml.xpath supported explicit data types defined by the XPath specification. However, it was missing the important ANY type without which the XPath API assumes that an explicit type is always known, which is not true in some circumstances. The new API now supports the ANY type so that an XPath evalution can be performed when the return type is unknown.

  1. Improved ease of use

For ease of use, four new evaluateExpression methods are added to the javax.xml.xpath.XPath and javax.xml.xpath.XPathExpression interfaces to allow specifying explicit types as follows:

When specified explicitly, the new methods return the specific types, including Boolean, Double, Integer, Long, String and org.w3c.dom.Node.

When the return type is expected to be NODESET, the new methods will return a new XPathNodes type. XPathNodes is a new interface that extends Iterable<Node> which makes it easier to use than the traditional org.w3c.dom.NodeList.

When the return type is unknown or ANY, the new methods return a new XPathEvaluationResult type. XPathEvaluationResult provides an XPathResultType enum that defines the supported types that are ANY, BOOLEAN, NUMBER, STRING, NODESET, and NODE.

See JDK-8054196






hotspot/runtime

Removal of rarely used sun.misc.Unsafe methods

The methods monitorEnter, monitorExit and tryMonitorEnter on sun.misc.Unsafe are removed in JDK 9. These methods are not used within the JDK itself and are very rarely used outside of the JDK.

See JDK-8054494






Since build 45  Integrations

hotspot/gc

Remove deprecated command line flags

These internal command line flags, which have been deprecated or aliased since JDK 6, have been removed:

CMSParPromoteBlocksToClaim, ParCMSPromoteBlocksToClaim, ParallelGCOldGenAllocBufferSize, ParallelGCToSpaceAllocBufferSize, UseGCTimeLimit, CMSPermGenSweepingEnabled, ResizeTLE, PrintTLE, TLESize, UseTLE, MaxTLERatio, TLEFragmentationRatio, TLEThreadRatio

In addition to this, these internal flags have been deprecated:

CMSMarkStackSizeMax, ParallelMarkingThreads, ParallelCMSThreads, CMSMarkStackSize, G1MarkStackSize

See JDK-8061611






Since build 44  Integrations

core-libs/java.util:i18n

Locale sensitive SPI and Input Method SPI implementations are now loaded from application's classpath

Up through JDK 8, SPI implementations of java.awt.im.spi, java.text.spi, and java.util.spi packages are loaded using Java Extension Mechanism. In JDK 9, this mechanism is no longer available. Instead, SPI implementations may be placed on an application's classpath.

See JDK-8062588






Since build 42  Integrations

core-libs/java.util.logging

Loggers with handlers configured from the logging.properties configuration file will not be garbage collected until LogManager.reset is called.

When a logger has a handler configured in the logging configuration file (using the <logger>.handlers property), a reference to that logger will be internally kept by the LogManager until LogManager.reset() is called, in order to ensure that the associated handlers are properly closed on reset. As a consequence, such loggers won't be garbage collected until LogManager.reset() is called. An application that needs to allow garbage collection of these loggers before reset is called can revert to the old behaviour by additionally specifying <logger>.handlers.ensureCloseOnReset=false in the logging configuration file. Note however that doing so will reintroduce the resource leak that JDK-8060132 is fixing. Such an application must therefore take the responsibility of keeping the logger alive as long as it is needed, and close any handler attached to it before the logger gets garbage collected. See LogManager API documentation for more details.

See JDK-8060132






security-libs/javax.xml.crypto

The XML Digital Signature API (javax.xml.crypto and subpackages) has been enhanced to better support generics

The XML Digital Signature APIs (the javax.xml.crypto package and subpackages) have been enhanced to better support Generics, as follows:

See JDK-8046949






Since build 37  Integrations

tools

extcheck tool removed

The extcheck tool has been removed in this release.

See JDK-8042888






hotspot/runtime

osset_native_thread_name() cleanups

On platforms that support the concept of a thread name on their native threads, the java.lang.Thread.setName() method will also set that native thread name. However, this will only occur when called by the current thread, and only for threads started through the java.lang.Thread class (not for native threads that have attached via JNI). The presence of a native thread name can be useful for debugging and monitoring purposes. Some platforms may limit the native thread name to a length much shorter than that used by the java.lang.Thread, which may result in some threads having the same native name.

See JDK-7102541






Since build 34  Integrations

other-libs/corba:idl

orb.idl and ir.idl moved to include directory

orb.idl and ir.idl have moved from the JDK lib directory to the include directory. Applications that use a CORBA IDL compiler in their build may need to change the include path from $JAVA_HOME/lib to $JAVA_HOME/include.

See JDK-8049389






Since build 31  Integrations

core-libs/java.lang:reflect

Updates to java.lang.reflect.Field.get(), Field.get{primitive}() and java.lang.reflect.Method.invoke()

java.lang.reflect.Field.get(), Field.get{primitive}() and java.lang.reflect.Method.invoke() have been updated to use the primitive wrapper classes' valueOf() (for example Integer.valueOf()) instead of always creating new wrappers with "new" (for example new Integer()) after the reflection libraries have (potentially) optimised the Field/Method instance. This can affect applications that depended on two wrappers being != while still being .equals().

See JDK-5043030






Since build 28  Integrations

core-libs/java.lang:reflect

Executable.getAnnotatedReceiverType() is sensitive to the kind of Executable

The behavior of getAnnotatedReceiverType() has been clarified to return an empty AnnotatedType object only for a method/constructor which could conceptually have a receiver parameter but does not have one at present. (Since there is no receiver parameter, there are no annotations to return.) In addition, the behavior of getAnnotatedReceiverType() has been clarified to return null for a method/constructor which cannot ever have a receiver parameter (and therefore cannot have annotations on the type of a receiver parameter): static methods, and constructors of non-inner classes. Incompatibility: Behavioral

See JDK-8044629






Since build 25  Integrations

core-libs/java.util

java.util.UUID#fromString(String) now throws IllegalArgumentException if the parameter is too long

As part of the fix for JDK-8006627, a check of the String parameter of java.util.UUID.fromString(String) was added which will result in an IllegalArgumentException being thrown if the length of the parameter is greater than 36.

See JDK-8006627






core-libs/javax.lang.model

for Provided new utility visitors supporting SourceVersion.RELEASE_9

The constructors for the utility visitors in javax.lang.model.util that correspond to the RELEASE_6 source level have been deprecated since the reference implementation regards -source 6 as obsolete. Authors of annotation processors should update their processors to support newer source versions.

See JDK-8050430






Since build 23  Integrations

security-libs/javax.security

Access ExtendedGSSContext.inquireSecContext() result through SASL

The output of ExtendedGSSContext.inquireSecContext() is now available as negotiated properties for the SASL GSSAPI mechanism using the name "com.sun.security.jgss.inquiretype.<type_name>", where "type_name" is the string form of the InquireType enum parameter in lower case. For example, "com.sun.security.jgss.inquiretype.krb5_get_session_key_ex" for the session key of an established Kerberos 5 security context.

See JDK-8044085






tools/javac

for Remove support for 1.5 and earlier source and target options

The javac command no longer supports -source or -target values for releases before 6/1.6. However, older class files are still readable by javac. Source code for older release can be ported to a newer source level. To generate class files usable by releases older than JDK 6, a javac from a JDK 6, 7, or 8 release family can be used.

See JDK-8011044






Since build 22  Integrations

security-libs/org.ietf.jgss:krb5

Support "include" and "includedir" in krb5.conf

The krb5.conf file now supports including other files using either the "include FILENAME" or "includedir DIRNAME" directives. FILENAME or DIRNAME must be an absolute path. The named file or directory must exist and be readable. Including a directory includes all files within the directory whose names consist solely of alphanumeric characters, dashes, or underscores. An included file can include other files but no recursion is allowed.

Also, before this change, when the same setting for a single-valued option (For example, default_realm) is defined more than once in krb5.conf, the last value was chosen. After this change, the first value is chosen. This is to be consistent with other krb5 vendors.

See JDK-8029994






security-libs/java.security

Disallow null values for Subject inputs

Inputs to the javax.security.auth.Subject class now prohibit null values in the constructors and modification operations on the Principal and credential Set objects returned by Subject methods.

For the non-default constructor, the principals, pubCredentials, and privCredentials parameters may not be null, nor may any element within the Sets be null. A NullPointerException will be thrown if null values are provided.

For operations performed on Set objects returned by getPrincipals(), getPrivateCredentials() and getPublicCredentials(), a NullPointerException is thrown under the following conditions:

See JDK-8015081






Since build 20  Integrations

core-svc/tools

management-agent.jar is removed.

management-agent.jar has been removed. Tools that have been using the Attach API to load this agent into a running VM should be aware that the Attach API has been updated in JDK 9 to define two new methods for starting a management agent:

See JDK-8043939






Since build 16  Integrations

security-libs/org.ietf.jgss:krb5

sun.security.krb5.KdcComm interprets kdc_timeout as msec instead of sec

An interoperability issue is found between Java and the native Kerberos implementation on BSD (including macOS) on the kdc_timeout setting in krb5.conf, where Java interpreted it as milliseconds and BSD as seconds when no unit is specified. This code change adds support for the "s" (second) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerned about interoperability between Java and BSD should use "5s".

See JDK-8036779






Since build 15  Integrations

client-libs/2d

Remove the com.sun.image.codec.jpeg package

com.sun.image.codec.jpeg has been shipped as a non-standard API since JDK v1.2. It was always advertised as a stop-gap measure until a proper standard equivalent was provided. That replacement (javax.imageio) has been there since JDK 1.4. As a result JDK 9 finally removes the long deprecated com.sun.image.codec.jpeg API which has been flagged as intended for removal for several releases. Applications which still depend on it will need to be re-coded in order to run on JDK9.

See JDK-8038838






core-svc/debugger

JDWP socket connector accept only local connections by default

The JDWP socket connector has been changed to bind to localhost only if no ip address or hostname is specified on the agent command line. A hostname of asterisk (*) may be used to achieve the old behavior which is to bind the JDWP socket connector to all available interfaces; this is not secure and not recommended.

JDK-8041435 (not public)






core-libs/java.io:serialization

serialver -show option is removed

The -show option to serialver has been removed in this release.

See JDK-8042887






hotspot/compiler

Remove BackEdgeThreshold flag

The -XX:BackEdgeThreshold flag has been removed because it is no longer supported. Users now need to use -XX:OnStackReplacePercentage instead.

See JDK-8021770






Since build 14  Integrations

core-libs/java.util

Properties loadFromXML/storeToXML methods do not support all encodings

java.util.Properties defines the loadFromXML andstoreToXML methods for Properties stored in XML documents. XML specifications only require XML processors to read entities in UTF-8 and UTF-16 and the API docs for these methods only require an implementation to support UTF-8 and UTF-16. The implementation of these methods has changed in JDK 9 to use a smaller XML parser which may impact applications that have been using these methods with other encodings. The new implementation does not have support all encodings that the legacy implementation had support for, in particular it does not support UTF-32/UCS-4, IBM* or x-IBM-* encodings. For maximum portability, applications are encouraged to use UTF-8 and UTF-16.

See JDK-8042889






hotspot/compiler

Remove EnableInvokeDynamic flag

The -XX:EnableInvokeDynamic flag has been removed because the VM does no longer support execution without invokedynamic.

See JDK-8036956






Since build 12  Integrations

tools/javac

implement eager resolution of return types

The compiler specification, see JLS8 18.5.2, modified the treatment of nested generic method invocations for which the return type is an inference variable. The compiler has been adapted to implement the new logic. This is important to minimize incompatibility with the javac 7 inference algorithm. Three cases are considered:

The compiler update implies an eager resolution for generic method invocations, provided that the return type is an inference variable.

See JDK-8030741






Since build 10  Integrations

core-libs/java.net

The lib/content-types.properties file has been removed

The lib/content-types.properties file has been removed from the Java run-time image. The lib/content-types.properties file contained the default MIME content-types table used to map content type to file extension, etc, and is used primarily by the URLConnection API. The lib/content-types.properties file was never intended to be user editable. Instead there is a system property, content.types.user.table, that allows one to define their own content types.

See JDK-8039362, for further details on the use of content.types.user.table.

See JDK-8039362






Since build 8  Integrations

security-libs/org.ietf.jgss:krb5

accept yes/no for boolean krb5.conf settings

Besides "true" and "false", krb5.conf now also accepts "yes" and "no" for boolean-valued settings.

See JDK-8029995






hotspot/compiler

Remove SafepointPollOffset flag

The -XX:SafepointPollOffset flag has been removed because it was introduced only to reproduce a problem with the C1 compiler and is no longer needed.

See JDK-8031203






Since build 3  Integrations

core-libs/java.lang:class_loading

Empty element in -Xbootclasspath/a will be skipped.

An empty element specified in -Xbootclasspath/a is skipped by the bootstrap class loader. This change might impact existing code that relies on an empty element in the boot class path to find resources in the current working directory. Such application will need to set the directory containing the resources be searched by the bootstrap class loader properly via -Xbootclasspath/a option.

See JDK-6760902






core-libs/java.lang:class_loading

"sun.lang.ClassLoader.allowArraySyntax" system property is no longer supported

sun.lang.ClassLoader.allowArraySyntax system property was introduced as a temporary workaround to give customers time to remove their source dependency on calling ClassLoader.loadClass with the array syntax that is not supported since JDK 6. This temporary workaround is removed in JDK 9 and setting sun.lang.ClassLoader.allowArraySyntax system property will have no effect to ClassLoader.loadClass. Existing code that calls ClassLoader.loadClass to create a Class object of an array class shall be replaced with Class.forName; otherwise it will get ClassNotFoundException.

See JDK-6516909






Since build 2  Integrations

security-libs/javax.net.ssl

Increase the priorities of GCM cipher suites

In TLS, a ciphersuite defines a specific set of cryptography algorithms used in a TLS connection. JSSE maintains a prioritized list of ciphersuites. In this update, GCM-based cipher suites are configured as the most preferable default cipher suites in the SunJSSE provider.

In the SunJSSE provider, the following ciphersuites are now the most preferred by default:

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256

TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
TLS_RSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384

TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
TLS_RSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256

Note that this is a behavior change of the SunJSSE provider in the JDK, it is not guaranteed to be examined and used by other JSSE providers. There is no guarantee the cipher suites priorities will remain the same in future updates or releases.

See JDK-8028518






security-libs/java.security

Add MD5 to jdk.certpath.disabledAlgorithms security property

In this update, MD5 is added to the jdk.certpath.disabledAlgorithms security property and the use of the MD5 hash algorithm in certification path processing is restricted in the Oracle JRE. Applications using certificates signed with a MD5 hash algorithm should upgrade their certificates as soon as possible.

Note that this is a behavior change of the Oracle JRE. It is not guaranteed that the security property (jdk.certpath.disabledAlgorithms) is examined and used by other JRE implementations.

JDK-8030829 (not public)






Since build 1  Integrations

core-libs/java.util.logging

Remove LogManager addPropertyChangeListener and removePropertyChangeListener methods

The deprecated addPropertyListener and removePropertyListener methods have been removed from java.util.logging.LogManager. Code that relies on a listener to be invoked when logging configuration changes should use the new addConfigurationListener and removeConfigurationListener methods instead.

See JDK-8029805






security-libs/javax.security

Remove com.sun.security.auth.callback.DialogCallbackHandler

The com.sun.security.auth.callback.DialogCallbackHandler class has been removed. This class, which is in the JDK-specific extensions to JAAS, was deprecated in JDK 8 and previously flagged for removal.

See JDK-8029904






core-libs/java.lang

Change SecurityManager checkTopLevelWindow, checkSystemClipboard, checkAccessAwtEventQueueAccess to check AllPermission

The deprecated checkTopLevelWindow, checkSystemClipboard, and checkAccessAwtEventQueueAccess in java.lang.SecurityManager have been changed to check AllPermission, they no longer check AWTPermission. Libraries that invoke these SecurityManager methods do to permission checks may require users of the library to change their policy files.

See JDK-8029886






core-libs/java.util.jar

Remove Packer/Unpacker addPropertyChangeListener and removePropertyListener methods

The deprecated addPropertyListener and removePropertyListener methods have been removed from java.util.jar.Pack200.Packer and java.util.jar.Pack200.Unpacker. Applications that need to monitor progress of a packer or unpacker should poll the value of the PROGRESS property instead.

See JDK-8029806






infrastructure/build

Remove Oracle Solaris ISA bin directories and links

On Oracle Solaris, the JDK and JRE no longer have an ISA (Instruction Specific Architecture) bin directory. The $JAVA_HOME/bin/sparcv9 and $JAVA_HOME/bin/amd64 directories, and the sym links in the directories, were present in JDK 8 to aid migration after 32-bit support was removed. Scripts or applications that rely on these locations should be updated to use $JAVA_HOME/bin.

See JDK-8029997






Delivered

security-libs/java.security

Change in the default keystore type to PKCS12

As of JDK 9, the default keystore type (format) is "pkcs12" which is based on the RSA PKCS12 Personal Information Exchange Syntax Standard. Previously, the default keystore type was "jks" which is a proprietary format. Other keystore formats are available, such as "jceks" which is an alternate proprietary keystore format with stronger encryption than "jks" and "pkcs11", which is based on the RSA PKCS11 Standard and supports access to cryptographic tokens such as hardware security modules and smartcards.

See JDK-8044445






core-libs

JEP 254 Compact Strings

In JDK 9 the internal character storage of the java.lang.String, StringBuilder and StringBuffer classes has been changed from a UTF-16 char array to a byte array plus a one-byte encoding-flag field. The new storage representation stores/encodes the characters either as ISO-8859-1/Latin-1 (one byte per character), or as UTF-16 (two bytes per character), based upon the contents of the string. The newly added encoding flag field indicates which encoding is used. This feature reduces, by 50%, the amount of space required for String objects to store the characters if the String object only contains single-byte/ latin-1 characters.

A new jvm option -XX:-CompactStrings has been introduced in JDK9 to disable this feature, which might be worth considering when

See JDK-8054307






core-svc/tools

jhat tool removed.

Experimental jhat tool has been removed.

See JDK-8059039






hotspot/gc

Various GC combinations have now been removed

The GC combinations that were deprecated in JDK 8 have now been removed. This means that the following GC combinations no longer exist:

The command line flags that were removed are: -Xincgc, -XX:+CMSIncrementalMode, -XX:+UseCMSCompactAtFullCollection, -XX:+CMSFullGCsBeforeCompaction and -XX:+UseCMSCollectionPassing.

The command line flag -XX:+UseParNewGC no longer has any effect. ParNew can only be used with CMS and CMS requires ParNew. Thus, the -XX:+UseParNewGC flag has been deprecated and will likely be removed in a future release.

See JDK-8044022






xml/jaxp

JAXP library updated with selected Xerces 2.11.0 updates

The JAXP library in JDK 9 has been updated to Xerces-J 2.11.0 release in the following areas:

This update includes improvement and bug fixes in the above areas up to the Xerces-J 2.11.0 release, but not the experimental support for XML Schema 1.1 features. Refer to Xerces-J 2.11.0 Release Notes for more details.

See JDK-8044086






tools/launcher

Remove Launch-Time JRE Version Selection

The Launch-Time JRE Version Selection also known as Multiple JRE or mJRE functionality will no longer be available with the java launcher. This means the java launcher will not invoke another JRE version, and will exit with an error.

The presence of "-version:x.y.z", "-jre-restrict-search" and "-jre-no-restrict-search" on the java launcher's command-line will cause it to exit with an error message. The environment variable "JRE_VERSION_PATH" will be ignored.

The Java Archive (jar) manifest entry "JRE-version" will cause the java launcher to emit a warning, and "JRE-Restrict-Search" will be ignored.

See JDK-8050071






hotspot/gc

JEP C175 Deprecate the Concurrent Mark Sweep (CMS) Garbage Collector in Oracle builds

The CMS garbage collector was deprecated in JDK 9. For more information, see -XX:+UseConcMarkSweepGC

JDK-8162744 (not public)