|Oracle® JRockit JDK Release Notes
|PDF · Mobi · ePub|
For information about bug fixes and changes in Java SE 6 Updates, see the release notes for JDK at:
It contains the following topics:
This section describes the changes in Oracle JRockit JDK R28.3.14:
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.
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.
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.
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.
This section describes the changes in Oracle JRockit JDK R28.3.13:
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.
JDK R28.3.13 contains IANA time zone data version 2016i. For more information, refer to Timezone Data Versions in the JRE Software
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:
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.
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)".
- 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 ``
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 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 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.transport.dgcFilter property pattern syntax is described in
JEP 290 and in
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
--allow-script-in-comments is specified.
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
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"
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.
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
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")
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 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.
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.
This section describes the changes in Oracle JRockit JDK R28.3.12:
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.
This section describes the changes in Oracle JRockit JDK R28.3.11:
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.
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:
This section describes the changes in Oracle JRockit JDK R28.3.10:
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.
This section describes the changes in Oracle JRockit JDK R28.3.9:
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.
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:
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
gcore cannot be used.
For more information about the
fork_and_abort command, see "Diagnostics Commands" in JRockit Command-Line Reference.
This section describes the changes in Oracle JRockit JDK R28.3.8:
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.
In this release, two new command-line options have been added for JVM diagnostics,
-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
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] 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)
This section describes the changes in Oracle JRockit JDK R28.3.2:
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
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.
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.
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.
This section describes the changes in Oracle JRockit JDK R28.2.3.
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.
This section describes the changes in Oracle JRockit JDK R28.2.2.
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.
This section describes the changes in Oracle JRockit JDK R28.2. These changes are:
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.
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.
This section lists the changes in Oracle JRockit JDK R28.1.5.
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.
This section lists the changes in JRockit JDK R28.1.0. These changes are:
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.
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.
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.
This section lists the changes in JRockit JDK R28.0.1.
The following are the new features and changes in JRockit JDK R28.0.0. These changes are:
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.
Heap dumps can now be generated in the HPROF binary format, which can be parsed using heap analysis tools. You can use the
-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.
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:codegen options is now more detailed. For more information, see the JRockit Command-Line Reference.
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.
In JRockit JVM R28.0, when you specify the
pausetime garbage collection mode by using the
-Xgc command-line option, the strategy associated with the specified mode— by default,
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
For more information about
-Xgc, see the JRockit Command-Line Reference.
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.
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.
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.
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.
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.
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.
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.
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.
In Oracle JRockit JVM R28.0, the format of several command-line options has been changed to the HotSpot format:
option (for example,
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.