Skip Headers
Oracle® JRockit JDK Release Notes
Release R28

E15066-42
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

2 New Features and Changes in Oracle JRockit JDK R28

This chapter describes the new features and changes in Oracle JRockit R28.x releases.

Note:

For information about bug fixes and changes in Java SE 6 Updates, see the release notes for JDK at:

http://www.oracle.com/technetwork/java/javase/overview-156328.html

It contains the following topics:

Changes in R28.3.16

This section describes the changes in Oracle JRockit JDK R28.3.16:

Upgraded to JDK 6u171

JRockit R28.3.16 is upgraded to JDK 6u171. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.

Support for SHA with DSA algorithms and DSA keys

Support has been added for the SHA224withDSA and SHA256withDSA signature algorithms and for DSA keys with sizes up to 2048 bits. Previously, only DSA keys with sizes up to 1024 bits were supported.

See JDK-7044060

Refactor Existing Providers to Refer to the Same Constants for Default Values for Key Length

security-libs/java.security

Two important changes have been made for this issue:

  • A new system property has been introduced that allows users to configure the default key size used by the JDK provider implementations of KeyPairGenerator and AlgorithmParameterGenerator. This property is named "jdk.security.defaultKeySize" and the value of this property is a list of comma-separated entries. Each entry consists of a case-insensitive algorithm name and the corresponding default key size (in decimal) separated by ":". In addition, white space is ignored.

    By default, this property does not have a value, and JDK providers use their own default values. Entries containing an unrecognized algorithm name will be ignored. If the specified default key size is not a parseable decimal integer, that entry will be ignored as well.

  • The DSA KeyPairGenerator implementation of the SUN provider no longer implements java.security.interfaces.DSAKeyPairGenerator. Applications which cast the SUN provider's DSA KeyPairGenerator object to a java.security.interfaces. The DSAKeyPairGenerator can set the system property "jdk.security.legacyDSAKeyPairGenerator". If the value of this property is "true", the SUN provider will return a DSA KeyPairGenerator object which implements the java.security.interfaces. The DSAKeyPairGenerator interface. This legacy implementation will use the same default value as specified by the javadoc in the interface.

    By default, this property will not have a value, and the SUN provider will return a DSAKeyPairGenerator object which does not implement the aforementioned interface and thus can determine its own provider-specific default value as stated in the java.security.KeyPairGenerator class or by the "jdk.security.defaultKeySize" system property if set.

Collections Use Serialization Filter to Limit Array Sizes

core-libs/java.util:collections

Deserialization of certain collection instances will cause arrays to be allocated. The ObjectInputFilter.checkInput() method is now called prior to allocation of these arrays.

  • Deserializing instances of ArrayDeque, ArrayList, IdentityHashMap, PriorityQueue, java.util.concurrent.CopyOnWriteArrayList, and the immutable collections (as returned by List.of, Set.of, and Map.of) will call checkInput() with a FilterInfo instance whose serialClass() method returns Object[].class.

  • Deserializing instances of HashMap, HashSet, Hashtable, and Properties will call checkInput() with a FilterInfo instance whose serialClass() method returns Map.Entry[].class.

In both cases, the FilterInfo.arrayLength() method returns the actual length of the array to be allocated. The exact circumstances under which the serialization filter is called, and with what information, is subject to change in future releases.

 Default Timeouts Have Changed for FTP URL Handler

core-libs/java.net

Timeouts used by the FTP URL protocol handler have been changed from infinite to 5 minutes. This will result in an IOException from connect and read operations if the FTP server is unresponsive. For example, new URL ("ftp://example.com").openStream().read(), will fail with java.net.SocketTimeoutException in case a connection or reading could not be completed within 5 minutes.

To revert this behaviour to that of previous releases, the following system properties may be used, sun.net.client.defaultReadTimeout=0, sun.net.client.defaultConnectTimeout=0

New Defaults for DSA Keys in Jarsigner and Keytool

security-libs/java.security

For DSA keys, the default signature algorithm for keytool and jarsigner has changed from SHA1withDSA to SHA256withDSA and the default key size for keytool has changed from 1024 bits to 2048 bits.

Users who want to revert to the previous behavior can use the -sigalg option of keytool and jarsigner and specify SHA1withDSA and the -keysize option of keytool and specify 1024.

There are a few potential compatibility risks associated with this change:

  • If you have a script that uses the default key size of keytool to generate a DSA keypair but then subsequently specifies a specific signature algorithm.

    For example:

    keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ...
    keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ...
    

    will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA:

    keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
    keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits
    

    The workaround is to remove the -sigalg option and use the stronger SHA256withDSA default or, at your own risk, use the -keysize option of keytool to specify a smaller key size (1024).

  • If you use jarsigner to sign JARs with the new defaults, previous versions (than this release) of JDK 6 and 7 do not support the stronger defaults and will not be able to verify the JAR. jarsigner -verify on an earlier release of JDK 6 or 7 will output the following error:

    jar is unsigned. (signatures missing or not parsable)
    

    If you add -J-Djava.security.debug=jar to the jarsigner command line, the cause will be output:

    jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available
    

    If compatibility with earlier releases is important, you can, at your own risk, use the -sigalg option of jarsigner and specify the weaker SHA1withDSA algorithm.

  • If you use a PKCS11 keystore, the SunPKCS11 provider does not support the SHA256withDSA algorithm. jarsigner and some keytool commands may fail with the following exception if PKCS11 is specified with the -storetype option. For example:

    keytool error: java.security.InvalidKeyException: No installed provider supports this key: sun.security.pkcs11.P11Key$P11PrivateKey
    

    A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the -sigalg option of keytool and specify SHA1withDSA.

See JDK-8057810

Changes in R28.3.15

This section describes the changes in Oracle JRockit JDK R28.3.15:

Upgraded to JDK 6u161

JRockit R28.3.15 is upgraded to JDK 6u161. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.

Improved Algorithm Constraints Checking

security-libs/java.security

With the need to restrict weak algorithms usage in situations where they are most vulnerable, additional features have been added when configuring the jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms security properties in the java.security file.

jdk.certpath.disabledAlgorithms

The certpath property has seen the most change. Previously it was limited to two constraint types – either a full disabling of an algorithm by name or a full disabling of an algorithm by the key size when checking certificates, certificate chains, and certificate signatures. This creates configurations that are absolute and lack flexibility in their usage. Three new constraints were added to give more flexibility in allowing and rejecting certificates.
  • jdkCA examines the certificate chain termination with regard to the cacerts file. In the case of SHA1 jdkCA. SHA1's usage is checked through the certificate chain, but the chain must terminate at a marked trust anchor in the cacerts keystore to be rejected. This is useful for organizations that have their own private CA that trust using SHA1 with their trust anchor, but want to block certificate chains anchored by a public CA from using SHA1.

  • denyAfter checks if the given date is before the current date or the PKIXParameter date. In the case of SHA1 denyAfter 2018-01-01, before 2018 a certificate with SHA1 can be used, but after that date, the certificate is rejected. This can be used for a policy across an organization that is phasing out an algorithm with a drop-dead date. For signed JAR files, the date is compared against the TSA timestamp. The date is specified in GMT.

  • usage examines the specified algorithm for a specified usage. This can be used when disabling an algorithm for all usages is not practical. There are three usages that can be specified:
    • TLSServer restricts the algorithm in TLS server certificate chains when server authentication is performed as a client.

    • TLSClient restricts the algorithm in TLS client certificate chains when client authentication is performed as a server.

    • SignedJAR restricts the algorithms in certificates in signed JAR files. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, SHA1 usage TLSServer TLSClient would disallow SHA1 certificates for TLSServer and TLSClient operations, but SignedJars would be allowed.

All of these constraints can be combined to constrain an algorithm when delimited by &. For example, to disable SHA1 certificate chains that terminate at marked trust anchors only for TLSServer operations, the constraint would be SHA1 jdkCA & usage TLSServer.

jdk.jar.disabledAlgorithms

One additional constraint was added to this .jar property to restrict JAR manifest algorithms.

denyAfter checks algorithm constraints on manifest digest algorithms inside a signed JAR file. The date given in the constraint is compared against the TSA timestamp on the signed JAR file. If there is no timestamp or the timestamp is on or after the specified date, the signed JAR file is treated as unsigned. If the timestamp is before the specified date, the .jar operates as a signed JAR file. The syntax for restricting SHA1 in JAR files signed after January 1st 2018 is: SHA1 denyAfter 2018-01-01. The syntax is the same as that for the certpath property, however certificate checking will not be performed by this property.

See JDK-8176536

JMX Diagnostic Improvements

core-svc/java.lang.management

The com.sun.management.HotSpotDiagnostic::dumpHeap API is modified to throw IllegalArgumentException 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 with IllegalArgumentException. 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.

Message Digest Algorithm for jarsigner -tsadigestalg Option Now Defaults to SHA-256

security-libs/java.security

If not specified, the message digest algorithm for the -tsadigestalg option of jarsigner defaults to SHA-256 (previously it was SHA-1). The -tsadigestalg option specifies the message digest algorithm that is used to generate the message imprint to be sent to the TSA server.

See JDK-8177674

Changes in R28.3.14

This section describes the changes in Oracle JRockit JDK R28.3.14:

Upgraded to JDK 6u151

JRockit R28.3.14 is upgraded to JDK 6u151. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.

IANA Data 2016j

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

See JDK-8170316

MD5 signature verification added to the Security Property jdk.jar.disabled Algorithms

security-libs/java.security

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 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 Security Manager enabled and are configured with a policy file that grants permissions based on the code signer of the JAR.

The list of disabled algorithms is controlled using the security property, jdk.jar.disabled Algorithms, 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 prints 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, this output would be displayed:

"The jar is 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 seen with 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 must 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.disabled Algorithms security property. However, this option is not recommended. Before re-signing affected JARs, the existing signature must 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'

Oracle recommends that you periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/cryptoroadmap for planned restrictions to signed JARs and other security components.

JDK-8171121

New system property to control caching for HTTP SPNEGO connection

core-libs/java.net

A new JDK implementation-specific system property to control caching for HTTP SPNEGO (Negotiate/Kerberos) connections is introduced. Caching for HTTP SPNEGO connections is enabled by default. There is no behavior change if the property is not explicitly specified.

When connecting to an HTTP server which 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 is recommended to disable all caching for the HTTP SPNEGO (Negotiate/Kerberos) protocol to force requesting new authentication with each new requests to the server.

With this fix, a new system property that allows control of the caching policy for HTTP SPNEGO connections is now provided. If jdk.spnego.cache is defined and evaluates to false, then all caching is 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 must be re-authenticated with each new request, requiring several communication exchanges with the server.

  • Credentials will need to be obtained again for each new requests, 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

New System Property to Control Caching for HTTP NTLM Connection

core-libs/java.net

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 is 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 the 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 is 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 is essential to disable all caching for the HTTP NTLM protocol to force requesting new authentication with each new request to the server.

With this fix, a new system property that allows control of the caching policy for HTTP NTLM connections is provided. If jdk.ntlm.cache is defined and evaluates to false, then all caching is disabled for HTTP NTLM connections. Setting this system property to false, however, results in undesirable side effects:

  • Performance of HTTP NTLM connections is severely impacted as the connection is re-authenticated with each new request, requiring several communication exchanges with the server.

  • Credentials must be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, results in a popup asking for credentials for every new request.

JDK-8163520

Changes in R28.3.13

This section describes the changes in Oracle JRockit JDK R28.3.13:

Upgraded to JDK 6u141

JRockit R28.3.13 is upgraded to JDK 6u141. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.

IANA Data 2016i

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

Improved protection for JNDI remote class loading

core-libs/javax.naming

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

jarsigner -verbose -verify should print the algorithms used to sign the jar

security-libs/java.security

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.disabled algorithms, 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

Added security property to configure XML Signature secure validation mode

security-libs/javax.xml.crypto

A new security property named jdk.xml.dsig.secureValidationPolicy has been added that allows you to configure the individual restrictions that are enforced when the secure validation mode of XML Signature is enabled. The default value for this property in the java.security configuration file is:

jdk.xml.dsig.secureValidationPolicy=\
    disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\
    maxTransforms 5,\
    maxReferences 30,\
    disallowReferenceUriSchemes file http https,\
    noDuplicateIds,\
    noRetrievalMethodLoops

Refer to the definition of the property in the java.security file for more information.

Serialization Filter Configuration

core-libs/java.io:serialization

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 <JRE>/lib/security/java.security. Filter actions are logged to the java.io.serialization logger, if enabled.

RMI Better constraint checking

core-libs/java.rmi

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 <JRE>/lib/security/java.security.

Add mechanism to allow non default root CAs to not be subject to algorithm restrictions

security-libs

In the java.security file, an additional constraint named jdkCA is added to the jdk.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 the lib/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

New --allow-script-in-comments option for javadoc

tools/javadoc(tool)

The javadoc tool will now reject any occurrences of JavaScript code in the javadoc documentation comments and command-line options, unless the command-line option, --allow-script-in-comments is specified.

With the --allow-script-in-comments option, the javadoc tool will preserve JavaScript code in documentation comments and command-line options. An error will be given by the javadoc tool if JavaScript code is found and the command-line option is not set.

Increase the minimum key length to 1024 for XML Signatures

security-libs/javax.xml.crypto

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 named jdk.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 property org.jcp.xml.dsig.secureValidation to true with the javax.xml.crypto.XMLCryptoContext.setProperty method, or by running the code with a SecurityManager.

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"

Make 3DES a legacy algorithm in the JSSE provider

security-libs/javax.net.ssl

For SSL/TLS/DTLS protocols, the security strength of 3DES cipher suites is not sufficient for persistent connections. By adding 3DES_EDE_CBC to the jdk.tls.legacyAlgorithms security property by default in JDK, 3DES cipher suites will not be negotiated unless there are no other candidates during the establishing of SSL/TLS/DTLS connections.

At their own risk, applications can update this restriction in the security property (jdk.tls.legacyAlgorithms) if 3DES cipher suites are really preferred.

Improve the default strength of elliptic curve cryptography in JDK

security-libs/javax.net.ssl

To improve the default strength of elliptic curve cryptography, elliptic curve 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).

Elliptic 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, 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

Restrict certificates with DSA keys less than 1024 bits

security-libs/java.security

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")

Add TLS v1.1 and v1.2 to the client list of default-enabled protocols

security-libs/javax.net.ssl

TLSv1.2 and TLSv1.1 are now enabled by default on the TLS client end-points. This is similar behavior to what already happens in JDK 8 releases.

See details from crypto roadmap for more details.

More checks added to DER encoding parsing code

security-libs

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.

Additional access restrictions for URLClassLoader.newInstance

core-libs/java.net

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 the jdk.net.URLClassPath.disableRestrictedPermissions system property.

Changes in R28.3.12

This section describes the changes in Oracle JRockit JDK R28.3.12:

Upgraded to JDK 6u131

JRockit R28.3.12 is upgraded to JDK 6u131. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.

Changes in R28.3.11

This section describes the changes in Oracle JRockit JDK R28.3.11:

Upgraded to JDK 6u121

JRockit R28.3.11 is upgraded to JDK 6u121. For more information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.

Support for TLS v1.2

TLS v1.2 is now a TLS protocol option available with the release of JDK 6u121 and JRockit R28.3.11. By default, TLS v1.0 will remain as the default enabled protocol on both client and server sides. For more information about enabling TLS v1.2, see the release notes for JDK 6u121 at:

http://www.oracle.com/technetwork/java/javase/overview-156328.html

Changes in R28.3.10

This section describes the changes in Oracle JRockit JDK R28.3.10:

Upgraded to JDK 6u115

JRockit R28.3.10 is upgraded to JDK 6u115. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.

Changes in R28.3.9

This section describes the changes in Oracle JRockit JDK R28.3.9:

Upgraded to JDK 6u111

JRockit R28.3.9 is upgraded to JDK 6u111. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.

Support for TLS v1.1

TLS v1.1 is now a TLS protocol option available with the release of JDK 6u111 and JRockit R28.3.9. By default, TLS v1.0 will remain as the default enabled protocol on both client and server sides. For more information about enabling TLS v1.1, see the release notes for JDK 6u111 at:

http://www.oracle.com/technetwork/java/javase/overview-156328.html.

New Diagnostic Command to Generate Core File

A new diagnostic command, fork_and_abort, has been added to generate core files from a JRockit process in environments where external tools such as gdb and gcore cannot be used.

For more information about the fork_and_abort command, see "Diagnostics Commands" in JRockit Command-Line Reference.

Changes in R28.3.8

This section describes the changes in Oracle JRockit JDK R28.3.8:

Upgraded to JDK 6u105

JRockit R28.3.8 is upgraded to JDK 6u105. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.

New Command-Line Options for Generating Core Dump Files on Exception

In this release, two new command-line options have been added for JVM diagnostics, -XX:AbortVMOnException and -XX:AbortVMOnExceptionMessage. These options are used to dump the JRockit text dump and a core file when an exception specified by -XX:AbortVMOnException and having an exception message specified by -XX:AbortVMOnExceptionMessage occurs.

Example:

java -XX:+UnlockDiagnosticVMOptions -XX:AbortVMOnException=InvalidClassException
-XX:AbortVMOnExceptionMessage="class invalid for deserialization" -Xverbose:exceptions DeserializeTest 

The above command dumps JRockit text dump and a core file when the specified InvalidClassException exception having the message "class invalid for deserialization" occurs. The -Xverbose output will be as follows:

[INFO ][excepti][00004] java/io/InvalidClassException: A; class invalid for deserialization
[ERROR] JRockit Fatal Error: Non-continuable exception (60)
[ERROR] Saw java/io/InvalidClassException, aborting
[JRockit] JVM State dumped to /export/test/jrockit.2091.dump.
Aborted (core dumped)

Changes in R28.3.2

This section describes the changes in Oracle JRockit JDK R28.3.2:

New Default Value for the -XX:+CheckStacks Command-Line Option

In JRockit versions prior to R28.3.2, the -XX:+|-CheckStacks option was disabled by default, meaning that JRockit did not explicitly check for stack overflows on a JNI method entry.

The -XX:+|-CheckStacks option in JRockit R28.3.2 and later versions will be enabled by default. In very rare cases, the additional overhead of stack overflow detection may result in low performance. This overhead can be avoided by explicitly disabling the stack checking by using the -XX:-CheckStacks option.

It is also possible, in very rare cases, that the system starts throwing StackOverflowErrors after enabling -XX:+|-CheckStacks. This happens only if the thread was within one page of memory from overflowing the stack. In this case, the recommended resolution is to increase the stack size by a small amount using the -Xss option, not by disabling -XX:+|-CheckStacks. For more information about the -Xss option, see JRockit Command-Line Reference.

New Command-Line Option to Disable Garbage Collection of Constant Pool

Applications that use a lot of reflection or serialization would suffer from the performance overhead of garbage collection activity that is required to help prune the runtime shared constant pool. This overhead can be eliminated with the new command line option -XX:-UseCPoolGC. Use of this option may result in native memory leaks.

For more information about this option, see -XX:-UseCPoolGC in JRockit Command-Line Reference.

New Verbose Option for Shutdown Report

A new parameter shutdown has been added to the -Xverbose option. When you set this parameter, JRockit provides information about any event that has triggered a normal shutdown of the JVM.

For more information, see the description of -Xverbose in JRockit Command-Line Reference.

Changes in R28.2.3

This section describes the changes in Oracle JRockit JDK R28.2.3.

New Default Value for the -XX:MaxLargePageSize Command-Line Option

In earlier versions of JRockit R28, the default value of the -XX:MaxLargePageSize option was zero, which means there was no limit for the maximum size for the large pages and the value was specified by the operating system.

The default value for this option in JRockit R28.2.3 and later versions will be 256 MB.

Changes in R28.2.2

This section describes the changes in Oracle JRockit JDK R28.2.2.

Fixed Issues in Finalization

Earlier versions of JRockit R28 suffered from an issue where some finalizers may never be executed. This issue was resolved in JRockit R28.2.2. Because JRockit uses finalizers internally to manage class constant pool data, a side effect of fixing this issue is that applications that continuously load and access the constant pool data of classes using sun.reflect.ConstantPool, may experience an increase in the number of finalizable objects stored on the Java heap after upgrading to R28.2.2 or later. In very rare cases, this additional pressure on the memory subsystem may result in performance issues (such as higher heap consumption or more GC activity) or even OutOfMemoryErrors. It is almost always possible to resolve such performance issues by modifying the application to eliminate redundant class loading.

Changes in R28.2.0

This section describes the changes in Oracle JRockit JDK R28.2. These changes are:

Improved JRockit Flight Recorder Heap Statistics Events

In earlier versions of JRockit R28, long garbage collections resulted in application pauses during profiling recording.

To avoid the long application pauses, the JRockit Flight Recorder Heap Statistics events have been improved.

Command-Line Options to Filter Exception Logging and Events

The new command-line option -XX:ExceptionTraceFilter and the new diagnostic command exception_trace_filter filter JVM exception logging and JRockit Flight Recorder exception events based on the exception type specified.

For more information about these commands, see Oracle JRockit Command-Line Reference.

Changes in R28.1.5

This section lists the changes in Oracle JRockit JDK R28.1.5.

JRockit Mission Control Samples are No Longer Installed by Default

The installer for Oracle JRockit JDK R28.1.5 with Oracle JRockit Mission Control 4.0.1 will not install JRockit Mission Control samples by default. You must select the optional component Demos and Samples to install JRockit Mission Control samples.

For more information about installing the product, see JRockit Installation and Upgrade Guide.

Changes in R28.1.0

This section lists the changes in JRockit JDK R28.1.0. These changes are:

Improved Garbage Collection

In the genpar garbage collection mode, when the nursery runs out of memory in the old generation, objects that are identified for promotion to the old space are promoted within the nursery and this resulted in fragmentation of the nursery. This situation is known as promotion failure.

In R28.1, the JRockit JVM prevents promotion failure by triggering an early old collection for those young collections that are running out of memory.

Command-Line Option to Specify the Receive Buffer Size

When reading from network sockets, the size of the receive buffer can be limited by using the new command-line option, -XX:MaxRecvBufferSize.

For more information about this option, see -XX:MaxRecvBufferSize in the JRockit Command-Line Reference.

Enabling JVM Crash When an Out-of-Memory Error Occurs

Oracle JRockit R28.1 introduces the command-line option -XX:[+|-]CrashOnOutOfMemoryError. If this option is enabled, when an out-of-memory error occurs, the JRockit JVM crashes and produces crash files. The state of the JVM before a crash is saved to a core dump file for off-line analysis.

For more information about this option, see -XX:+|-CrashOnOutOfMemoryError in the JRockit Command-Line Reference.

Collecting and Packaging Flight Recording Data from Disk Buffers

This release of Oracle JRockit introduces the command-line tool oracle.jrockit.jfr.tools.ConCatRepository, that allows you to extract JRockit Flight Recorder data that has been written to disk, but not handled and packaged as a flight recording, and then create a flight recording from it. This feature is useful when you have flight recording buffers on disk and the JVM terminates in such a way that .jfr files are not assembled to a complete flight recording file.

For more information, see the JRockit Flight Recorder Run Time Guide.

Changes in R28.0.1

This section lists the changes in JRockit JDK R28.0.1.

Default MaxCodeMemory on Linux IA32 with Large Pages Increased to 64 MB

The default maximum code memory on Linux IA32 with large pages was 32 MB in R28.0.0.

In R28.0.1, the default value has been changed to 64 MB.

For more information, see -XX:MaxCodeMemory in the JRockit Command-Line Reference.

New Features and Changes in R28.0.0

The following are the new features and changes in JRockit JDK R28.0.0. These changes are:

Change in Thread Suspension Mechanism

The mechanism to stop threads in the JVM has been changed. In previous releases of the JRockit JVM, threads were suspended (for performing garbage collection, for example) by sending signals. In JRockit JVM R28.0, the threads check periodically whether they should self-suspend.

This change does not result in visible behavioral changes, but it makes the JRockit JVM easier to maintain and less error-prone.

Ability to Generate HPROF-Formatted Heap Dumps

Heap dumps can now be generated in the HPROF binary format, which can be parsed using heap analysis tools. You can use the -XX:+HeapDumpOnOutOfMemoryError or -XX:+HeapDumpOnCtrlBreak command-line options to generate Java heap dumps in HPROF binary format on OutOfMemory errors. You can also generate heap dumps in HPROF format by using the hprof diagnostic command and through JRockit Mission Control.

For more information, see "Generating Java Heap Dumps in the HPROF Binary Format" in the JRockit Diagnostics and Troubleshooting Guide.

Improved Logging for Code Generation and Optimization

The granularity of logging for code generation and optimization has been increased, to enable faster diagnostics and troubleshooting. The information in the outputs of the -Xverbose:opt and -Xverbose:codegen options is now more detailed. For more information, see the JRockit Command-Line Reference.

Better Control Over Code Optimization Through Directives

In previous releases of the JRockit JVM, you could control code optimization by specifying directives in an optfile and then using the -Djrockit.optfile property to indicate the name and location of the optfile.

In JRockit JVM R28.0, the format for specifying compiler-control directives in the optfile has been extended and improved to enable control over code optimization at a more detailed level. A new diagnostic command-line option, -XX:OptFile, is available for specifying the name and path of the optfile.

For more information, see "Specifying Optimization Directives" in the JRockit Diagnostics and Troubleshooting Guide.

Garbage Collection Strategy Does Not Change at Run Time

In JRockit JVM R28.0, when you specify the throughput or pausetime garbage collection mode by using the -Xgc command-line option, the strategy associated with the specified mode— by default, genpar and gencon respectively—is used throughout the run time. The garbage collector does not change between generational and nongenerational garbage collectors during the run time.

This change has been made to reduce the extent of underterministic garbage collection behavior due to strategy changes during run time.

Note that the -XgcPrio option continues to work in R28.0. Oracle recommends that you use the -Xgc option instead of using the -XgcPrio option.

For more information about -Xgc, see the JRockit Command-Line Reference.

Large Objects Are Allocated in the Nursery

Oracle JRockit JVM R28.0 allocates large objects in the nursery if the size of the object is within the limit specified by the -XXtlaSize:wasteLimit command-line option.

This change improves the utilization of the nursery and reduces the frequency of old-space garbage collections.

For more information about -XXtlaSize:wasteLimit, see the JRockit Command-Line Reference.

Single Command-Line Option to Specify Compaction Behavior

Oracle JRockit R28.0 supports a new command-line option that enables you to specify compaction-related behavior: -XXcompaction. This option accepts all the parameters for compaction: compaction percentage, maximum number of references, and so on.

All the other compaction-related options are deprecated in R28.0.

For more information about -XXcompaction, see the JRockit Command-Line Reference.

Changes in the JMX Agent

In JRockit JVM R28.0, after the local management service starts, it remains active until the JVM is terminated.

In previous releases, the performance counter memory used to leak, and new addresses of the JMX connector were written during a memory leakage. Therefore, the JMX client was reading the wrong address of the JMX connector. This issue has been fixed in R28.0.

To allow RMI communication between the JRockit JVM server and a client through a firewall, two ports (RMI Registry and RMI Server) are required to configure the firewall. In previous releases, the RMI Server port number was generated randomly on the JRockit JVM server; so it was not possible to configure the firewall in advance. In JRockit JVM R28.0, the JMX agent enables you to select the same port number for the RMI Registry and the RMI Server. Therefore, you can use the default JMX agent for RMI communication through a firewall.

You can set the JMX agent properties by using the system properties or by using the -Xmanagement command-line option. For more information about the JMX agent system properties, see Appendix B "JMX Agent-Related –D Options" in the JRockit Command-Line Reference.

Compressed References for Larger Heaps

Oracle JRockit JVM R28.0 supports up to 64 GB compressed references for various heap sizes. You can define the compressed reference size during the JVM startup by using the -XXcompressedRefs command-line option.

For more information about -XXcompressedRefs, see the JRockit Command-Line Reference.

Changes in Heap Sizing

In JRockit JVM R28.0, the heap grows faster than before. The JVM also ensures that the heap size grows up to the maximum Java heap size (-Xmx) before an OutofMemory error is thrown. In addition, the default value of the -Xmx option is changed from 1 GB to 3 GB on 64-bit platforms.

The JRockit JVM shrinks the heap if it is unused or if other applications require more physical memory.

In the previous releases, the JVM used to crash when the heap size reduced from a very large size to a small size. This issue has been fixed in R28.0.

Change in Class and Code Garbage Collection

The pause time during the old collection of code and class garbage collections has been removed in Oracle JRockit JVM R28.0. With this change, the code and class garbage collections are mostly concurrent in R28.0.

New Command-Line Options in R28.0

The Oracle JRockit JVM R28.0 supports several new command-line options.

For more information, see Appendix A, "Changes in Command-Line Options" in the JRockit Command-Line Reference.

Command-Line Options Deprecated in R28.0

Some command-line options have been deprecated in Oracle JRockit JVM R28.0.

For more information, see Appendix A, "Changes in Command-Line Options" in the JRockit Command-Line Reference.

Command-Line Options Changed to the HotSpot Format in R28.0

In Oracle JRockit JVM R28.0, the format of several command-line options has been changed to the HotSpot format: -XX:+|-option (for example, -XX:+UseClassGC).

For a list of the command-line options that have been changed to the HotSpot format, see Appendix A, "Changes in Command-Line Options" in the JRockit Command-Line Reference.