8u141 Update Release Notes

JDK 8 Update Release Notes

---

Java™ SE Development Kit 8, Update 141 (JDK 8u141)

July 18, 2017

The full version string for this update release is 1.8.0_141-b15 (where "b" means "build"). The version number is 8u141.

IANA Data 2017b

JDK 8u141 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u141 are specified in the following table:

JRE Family Version	JRE Security Baseline (Full Version String)
8	1.8.0_141-b15
7	1.7.0_151-b15
6	1.6.0_161-b13

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u141) will expire with the release of the next critical patch update scheduled for October 17, 2017.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u141) on November 17, 2017. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

Known Issues

deploy/webstart

JAR file validation changes

After upgrading to the JDK July CPU release (8u141/7u151/6u161), when executing Java Webstart applications, customers may encounter an exception like
“java.lang.SecurityException: digest missing for …” that prevents the application from loading.

The issue is observed in signed JAR files whose manifest contains package version information[1] and does not have a trailing "/" in the name of the package (e.g.: Name:org/apache/xml/resolver). While we work towards resolving this issue, in the interim, users can work-around the issue as follows:

NOTE: We recommend use of this workaround only if the distributor of the JAR files can "re-sign" the JAR files.

1. Extract the contents of the signed JAR file (e.g.: jar xf jar-file ).
2. Modify META-INF/MANIFEST.MF file and add a trailing “/” to the name of the package ( e.g.: Name: org/apache/xml/resolver/).
3. Remove the current signature files ( e.g.: rm -f META-INF/*.SF META-INF/*.RSA META-INF/*.DSA ).
4. Recreate the JAR file ( e,g.: jar cfm jar-file META-INF/MANIFEST.MF input-file(s) ).

NOTE: You must use the jar utility. Other jar creation tools might re-introduce the issue.

5. Re-sign the JAR file.

[1]https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp91706

See JDK-8184993

Certificate Changes

New Let's Encrypt certificates added to root CAs

One new root certificate has been added:

ISRG Root X1 
alias: letsencryptisrgx1 
DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US

JDK-8177539 (not public)

New Features

security-libs/java.security

Disable SHA-1 TLS Server Certificates

Any TLS server certificate chain containing a SHA-1 certificate (end-entity or intermediate CA) and anchored by a root CA certificate included by default in Oracle's JDK is now blocked by default. TLS Server certificate chains that are anchored by enterprise or private CAs are not affected. Only X.509 certificate chains that are validated by the PKIX implementation of the CertPathValidator andCertPathBuilder APIs and the SunX509 and PKIX implementations of theTrustManagerFactory API are subject to the restrictions. Third-party implementations of these APIs are directly responsible for enforcing their own restrictions.

To implement this restriction and provide more flexibility for configuring your own restrictions, additional features have been added to the jdk.certpath.disabledAlgorithms andjdk.jar.disabledAlgorithms Security Properties in the java.security file, as follows:

• jdk.certpath.disabledAlgorithms:
  Three new constraints have been added to this Security Property:
  A new constraint named jdkCA, that when set, restricts the algorithm if it is used in a certificate chain that is anchored by a trust anchor that is pre-installed in the JDK cacerts keystore. This condition does not apply to certificate chains that are anchored by other certificates, including those that are subsequently added to the cacerts keystore. Also, note that the restriction does not apply to trust anchor certificates, since they are directly trusted.
  A new constraint named denyAfter, that when set, restricts the algorithm if it is used in a certificate chain after the specified date. The restriction does not apply to trust anchor certificates, since they are directly trusted. Also, code signing certificate chains as used in signed JARs are treated specially as follows:
  • if the certificate chain is used with a signed JAR that is not timestamped, it will be restricted after the specified date
  • if the certificate chain is used with a signed JAR that is timestamped, it will not be restricted if it is timestamped before the specified date. If the JAR is timestamped after the specified date, it will be restricted.
  A new constraint named usage, that when set, restricts the algorithm if it is used in a certificate chain for the specified use(s). Three usages are initially supported: TLSServer for TLS/SSL server certificate chains, TLSClient for TLS/SSL client certificate chains, andSignedJAR for certificate chains used with signed JARs.

Multiple constraints can be combined to constrain an algorithm when delimited by '&'. For example, to disable SHA-1 TLS Server certificate chains that are anchored by pre-installed root CAs, the constraint is "SHA1 jdkCA & usage TLSServer".

• jdk.jar.disabledAlgorithms:
  A new constraint has been added named denyAfter, that when set, restricts the algorithm if it is used in a signed JAR after the specified date, as follows:
  • if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date
  • if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. If the JAR is timestamped after the specified date, it will be restricted.
  For example, to restrict SHA1 in JAR files signed after January 1st 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". The syntax is the same as the certpath property, however certificate checking will not be performed by this property.

See JDK-8176536

Changes

core-svc/java.lang.management

JMX Diagnostic improvements

com.sun.management.HotSpotDiagnostic::dumpHeap API is modified to throwIllegalArgumentException if the supplied file name does not end with “.hprof” suffix. Existing applications which do not provide a file name ending with the “.hprof” extension will fail withIllegalArgumentException. In that case, applications can either choose to handle the exception or restore old behavior by setting system property 'jdk.management.heapdump.allowAnyFileSuffix' to true.

JDK-8176055 (not public)

security-libs/javax.net.ssl

Custom HostnameVerifier enables SNI extension

Earlier releases of JDK 8 Updates didn't always send the Server Name Indication (SNI) extension in the TLS ClientHello phase if a custom hostname verifier was used. This verifier is set via thesetHostnameVerifier(HostnameVerifier v) method in HttpsURLConnection. The fix ensures the Server Name is now sent in the ClientHello body.

See JDK-8144566

xml/jax-ws

Tighter secure checks on processing WSDL files by wsimport tool

The wsimport tool has been changed to disallow DTDs in Web Service descriptions, specifically:

• DOCTYPE declaration is disallowed in documents
• External general entities are not included by default
• External parameter entities are not included by default
• External DTDs are completely ignored

To restore the previous behavior:

• Set the System property com.sun.xml.internal.ws.disableXmlSecurity to true
• Use the wsimport tool command line option –disableXmlSecurity
  NOTE: JDK 7 and JDK 6 support for this option in wsimport will be provided via a Patch release post July CPU

JDK-8182054 (not public)

Bug Fixes

This release contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see theJDK 8u141 Bug Fixes page.

- Link:

- wong chee tat :)

8u131 Update Release Notes

April 18, 2017

JDK 8 Update Release Notes

---

Java™ SE Development Kit 8, Update 131 (JDK 8u131)

The full version string for this update release is 1.8.0_131-b11 (where "b" means "build"). The version number is 8u131.

IANA Data 2016j

JDK 8u131 contains IANA time zone data version 2016j. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u131 are specified in the following table:

JRE Family Version	JRE Security Baseline (Full Version String)
8	1.8.0_131-b11
7	1.7.0_141-b11
6	1.6.0_151-b10

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u131) will expire with the release of the next critical patch update scheduled for July 18, 2017.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u131) on August 18, 2017. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

Changes

security-libs/java.security
MD5 added to jdk.jar.disabledAlgorithms Security property
This JDK release introduces a new restriction on how MD5 signed JAR files are verified. If the signed JAR file uses MD5, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:

• Applets or Web Start Applications
• Standalone or Server Applications that are run with a SecurityManager enabled and are configured with a policy file that grants permissions based on the code signer(s) of the JAR file.

The list of disabled algorithms is controlled via the security property,jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.

To check if a weak algorithm or key was used to sign a JAR file, one can use the jarsigner binary that ships with this JDK. Running "jarsigner -verify" on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use the following command:

jarsigner -verify test.jar

If the file in this example was signed with a weak signature algorithm like MD5withRSA, the following output would be displayed:

The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled. Re-run jarsigner with the -verbose option for more details.

More details can be displayed by using the verbose option:

jarsigner -verify -verbose test.jar

The following output would be displayed:

- Signed by "CN=weak_signer" 
    Digest algorithm: MD5 (weak) 
    Signature algorithm: MD5withRSA (weak), 512-bit key (weak) 
  Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 
    Timestamp digest algorithm: SHA-256 
    Timestamp signature algorithm: SHA256withRSA, 2048-bit key

To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size. Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JARs, the existing signature(s) should be removed from the JAR file. This can be done with the .zip utility, as follows:

zip -d test.jar 'META-INF/.SF' 'META-INF/.RSA' 'META-INF/*.DSA' 

Please periodically check the Oracle JRE and JDK Cryptographic Roadmap athttp://java.com/cryptoroadmap for planned restrictions to signed JARs and other security components.
JDK-8171121 (not public)

core-libs/java.net
New system property to control caching for HTTP SPNEGO connection.
A new JDK implementation specific system property to control caching for HTTP SPNEGO (Negotiate/Kerberos) connections is introduced. Caching for HTTP SPNEGO connections remains enabled by default, so if the property is not explicitly specified, there will be no behavior change.

When connecting to an HTTP server that uses SPNEGO to negotiate authentication, and when connection and authentication with the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP server using SPNEGO usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP SPNEGO (Negotiate/Kerberos) protocol in order to force requesting new authentication with each new request to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP SPNEGO connections. If jdk.spnego.cache is defined and evaluates to false, then all caching will be disabled for HTTP SPNEGO connections. Setting this system property to false may, however, result in undesirable side effects:

• Performance of HTTP SPNEGO connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
• Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.

JDK-8170814 (not public)

core-libs/java.net
New system property to control caching for HTTP NTLM connection.
A new JDK implementation specific system property to control caching for HTTP NTLM connection is introduced. Caching for HTTP NTLM connection remains enabled by default, so if the property is not explicitly specified, there will be no behavior change.

On some platforms, the HTTP NTLM implementation in the JDK can support transparent authentication, where the system user credentials are used at system level. When transparent authentication is not available or unsuccessful, the JDK only supports getting credentials from a global authenticator. If connection to the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP NTLM server usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP NTLM protocol in order to force requesting new authentication with each new requests to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP NTLM connections. If jdk.ntlm.cache is defined and evaluates to false, then all caching will be disabled for HTTP NTLM connections. Setting this system property to false may, however, result in undesirable side effects:

• Performance of HTTP NTLM connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
• Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.

JDK-8163520 (not public)

tools/visualvm
New version of VisualVM
VisualVM 1.3.9 was released on October 4th, 2016 http://visualvm.github.io/relnotes.html and has been integrated into 8u131.
See JDK-8167485

Bug Fixes

The following are some of the notable bug fixes included in this release:

client-libs/java.awt
Introduced a new window ordering model
On the OS X platform, the AWT framework used native services to implement parent-child relationship for windows. That caused some negative visual effects especially in multi-monitor environments. To get rid of the disadvantages of such an approach, the new window ordering model, which is fully implemented at the JDK layer, was introduced. Its main principles are listed below:

• A window should be placed above its nearest parent window.
• If a window has several child windows, all child windows should be located at the same layer and the window from the active window chain should be ordered above its siblings.
• Ordering should not be performed for a window that is in an iconified state or when the transition to an iconified state is in progress.

These rules are applied to every frame or dialog from the window hierarchy that contains the currently focused window.
See JDK-8169589

security-libs/javax.net.ssl
Correction of IllegalArgumentException from TLS handshake
A recent issue from the JDK-8173783 fix can cause issue for some TLS servers. The problem originates from an IllegalArgumentException thrown by the TLS handshaker code:

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves
The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified.
See JDK-8173783

This release also contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see theJDK 8u131 Bug Fixes page.

Installed!

- wong chee tat :)

8u121 Update Release Notes

January 17, 2017

JDK 8 Update Release Notes

---

Java™ SE Development Kit 8, Update 121 (JDK 8u121)

The full version string for this update release is 1.8.0_121-b13 (where "b" means "build"). The version number is 8u121.

IANA Data 2016i

JDK 8u121 contains IANA time zone data version 2016i. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 8u121 are specified in the following table:

JRE Family Version	JRE Security Baseline (Full Version String)
8	1.8.0_121-b13
7	1.7.0_131-b12
6	1.6.0_141-b12

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 8u121) will expire with the release of the next critical patch update scheduled for April 18, 2017.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u121) on May 18, 2017. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

Notes

core-libs/javax.naming
Improved protection for JNDI remote class loading
Remote class loading via JNDI object factories stored in naming and directory services is disabled by default. To enable remote class loading by the RMI Registry or COS Naming service provider, set the following system property to the string "true", as appropriate:

com.sun.jndi.rmi.object.trustURLCodebase
    com.sun.jndi.cosnaming.object.trustURLCodebase

JDK-8158997 (not public)

security-libs/java.security
jarsigner -verbose -verify should print the algorithms used to sign the jar
The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak.

Specifically, when "jarsigner -verify -verbose filename.jar" is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property, jdk.jar.disabledAlgorithms, it will be labeled with "(weak)".

For example:

- Signed by "CN=weak_signer"
   Digest algorithm: MD2 (weak) 
   Signature algorithm: MD2withRSA (weak), 512-bit key (weak)
 Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016
   Timestamp digest algorithm: SHA-256 
   Timestamp signature algorithm: SHA256withRSA, 2048-bit key 

See JDK-8163304 

New Features

core-libs/java.io:serialization
Serialization Filter Configuration
Serialization Filtering introduces a new mechanism which allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Every ObjectInputStream applies a filter, if configured, to the stream contents during deserialization. Filters are set using either a system property or a configured security property. The value of the "jdk.serialFilter" patterns are described in JEP 290 Serialization Filtering and in /lib/security/java.security. Filter actions are logged to the 'java.io.serialization' logger, if enabled. 
See JDK-8155760

core-libs/java.rmi
RMI Better constraint checking
RMI Registry and Distributed Garbage Collection use the mechanisms of JEP 290 Serialization Filtering to improve service robustness.
RMI Registry and DGC implement built-in white-list filters for the typical classes expected to be used with each service.
Additional filter patterns can be configured using either a system property or a security property. The "sun.rmi.registry.registryFilter" and "sun.rmi.transport.dgcFilter" property pattern syntax is described in JEP 290 and in /lib/security/java.security.
JDK-8156802 (not public)

security-libs
Add mechanism to allow non-default root CAs to not be subject to algorithm restrictions
*New certpath constraint: jdkCA*
In the java.security file, an additional constraint named "jdkCA" is added to thejdk.certpath.disabledAlgorithms property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in thelib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression.

Example: To apply this constraint to SHA-1 certificates, include the following: SHA1 jdkCA
See JDK-8140422

Changes

security-libs/javax.xml.crypto
Increase the minimum key length to 1024 for XML Signatures
The secure validation mode of the XML Signature implementation has been enhanced to restrict RSA and DSA keys less than 1024 bits by default as they are no longer secure enough for digital signatures. Additionally, a new security property namedjdk.xml.dsig.SecureValidationPolicy has been added to the java.security file and can be used to control the different restrictions enforced when the secure validation mode is enabled.

The secure validation mode is enabled either by setting the xml signature propertyorg.jcp.xml.dsig.secureValidation to true with thejavax.xml.crypto.XMLCryptoContext.setProperty method, or by running the code with aSecurityManager.

If an XML Signature is generated or validated with a weak RSA or DSA key, an XMLSignatureException will be thrown with the message, "RSA keys less than 1024 bits are forbidden when secure validation is enabled" or "DSA keys less than 1024 bits are forbidden when secure validation is enabled."
JDK-8140353 (not public)

docs/release_notes
Restrict certificates with DSA keys less than 1024 bits.
DSA keys less than 1024 bits are not strong enough and should be restricted in certification path building and validation. Accordingly, DSA keys less than 1024 bits have been deactivated by default by adding "DSA keySize < 1024" to the "jdk.certpath.disabledAlgorithms" security property. Applications can update this restriction in the security property ("jdk.certpath.disabledAlgorithms") and permit smaller key sizes if really needed (for example, "DSA keySize < 768").
JDK-8139565 (not public)

security-libs
More checks added to DER encoding parsing code
More checks are added to the DER encoding parsing code to catch various encoding errors. In addition, signatures which contain constructed indefinite length encoding will now lead to IOException during parsing. Note that signatures generated using JDK default providers are not affected by this change.
JDK-8168714 (not public)

core-libs/java.net
Additional access restrictions for URLClassLoader.newInstance
Class loaders created by the java.net.URLClassLoader.newInstance methods can be used to load classes from a list of given URLs. If the calling code does not have access to one or more of the URLs and the URL artifacts that can be accessed do not contain the required class, then a ClassNotFoundException, or similar, will be thrown. Previously, a SecurityException would have been thrown when access to a URL was denied. If required to revert to the old behavior, this change can be disabled by setting thejdk.net.URLClassPath.disableRestrictedPermissions system property.
JDK-8151934 (not public)

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 tojava.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. Seejava.util.logging.LogManager and java.util.logging.FileHandler API documentation for more details. 
See JDK-8153955
  

Bug Fixes

The following are some of the notable bug fixes included in this release: 

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 theMouseWheelEvent.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 theMouseWheelEvent.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

This release also contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see theJDK 8u121 Bug Fixes page.

Known Issues

deploy/packager
javapackager and fx:deploy bundle the whole JDK instead of JRE
There is a known bug in the Java Packager for Mac where the entire JDK may be bundled with the application bundle resulting in an unusually large bundle. The work around is to use the bundler option -Bruntime option. For example: -Bruntime=JavaAppletPlugin.plugin sets where theJavaAppletPlugin.plugin for the desired JRE to bundle is located in the current directory.
See JDK-8166835

install/install
Java Installation will fail for non-admin users with UAC off
The Java installation on Windows will fail without warning or prompting, for non-admin users with User Access Control (UAC) disabled. The installer will leave a directory, jds<number>.tmp, in the %TEMP% directory.
JDK-8161460 (not public)

- wong chee tat :)