Skip Headers
Oracle® JRockit JDK Release Notes
Release R28

E15066-39
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.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

Please 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, please update the System Property accordingly. For example:

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

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

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.