Removal of javac Support for 6/1.6 source, target, and release Values

Consistent with the policy outlined in JEP 182: Policy for Retiring javac -source and -target Options, support for the 6/1.6 argument value for javac's -source, -target, and --release flags has been removed.

Changed Properties.loadFromXML to Comply with Specification

The implementation of the java.util.Properties.loadFromXML method has been changed to comply with its specification. Specifically, the underlying XML parser implementation now rejects non-compliant XML documents by throwing an InvalidPropertiesFormatException as specified by the loadFromXML method.

The effect of the change is as follows:

• Documents created by Properties.storeToXML: No change. Properties.loadFromXML will have no problem reading such files.

• Documents not created by Properties.storeToXML: Any documents containing DTDs not in the format as specified in Properties.loadFromXML will be rejected. This means the DTD shall be exactly as follows (as generated by the Properties.storeToXML method):

` <!DOCTYPE properties SYSTEM "http://java.sun.com/dtd/properties.dtd"> `

Changed URLPermission Behavior with Query or Fragments in URL String

The behavior of java.net.URLPermission has changed slightly. It was previously specified to ignore query and fragment components in the supplied URL string. However, this behavior was not implemented and any query or fragment were included in the internal permission URL string. The change here is to implement the behavior as specified. Internal usages of URLPermission in the JDK do not include queries or fragments. So, this will not change. In the unlikely event that user code was creating URLPermission objects explicitly, then the behavior change may be seen and that permission checks which failed erroneously previously, will now pass as expected.

can_pop_frame and can_force_early_return Capabilities are Disabled if JVMCI Compiler is Used

The JVMTI can_pop_frame and can_force_early_return capabilities are disabled if a JVMCI compiler (like Graal) is used. As a result the corresponding functionality (PopFrame and ForceEarlyReturnXXX functions) is not available to JVMTI agents. This issue is tracked by JDK-8218885.

Square Character Support for Japanese New Era

The code point, U+32FF, is reserved by the Unicode Consortium to represent the Japanese square character for the new era that begins from May, 2019. Relevant methods in the Character class return the same properties as the existing Japanese era characters (e.g., U+337E for "Meizi"). For details about the code point, see http://blog.unicode.org/2018/09/new-japanese-era.html.

POSIX_SPAWN Option on Linux

As an additional way to launch processes on Linux, the jdk.lang.Process.launchMechanism property can be set to POSIX_SPAWN. This option has been available for a long time on other *nix platforms. The default launch mechanism (VFORK) on Linux is unchanged, so this additional option does not affect existing installations.

POSIX_SPAWN mitigates rare pathological cases when spawning child processes, but it has not yet been excessively tested. Prudence is advised when using POSIX_SPAWN in productive installations.

Initial Value of user.timezone System Property Changed

The initial value of the `user.timezonesystem property is undefined unless set using a command line argument, for example, ``-Duser.timezone="America/New_York"``. The first time the default timezone is needed, ifuser.timezoneis undefined or empty the timezone provided by the operating system is used. Previously, the initial value was the empty string. In JDK 12,System.getProperty("user.timezone")` may return null.

JEP 325: Switch Expressions (Preview)

The Java language enhances the switch statement so that it can be used as either a statement or an expression. Using switch as an expression often results in code that is more concise and readable. Both the statement and expression form can use either traditional case ... : labels (with fall through) or simplified case ... -> labels (no fall through). Also, both forms can switch on multiple constants in one case. These enhancements to switch are a preview language feature.

Make -Xshare:auto the default for server VM

We expect CDS to be widely used with the Server VM. However, the current default CDS setting for Server VM is -Xshare:off. This makes it cumbersome to use CDS.

We should change the default to -Xshare:auto, so as long as a CDS archive exists in the JDK, CDS will be automatically used without specifying extra flags.

In JDK 8 and before, RewriteBytecodes was disabled when CDS was enabled. This caused performance degradation in the Server Compiler (aka C2). However this has been fixed in JDK-8074345 since JDK 9, so there's no longer need to disable CDS by default with the Server VM.

The proposed change is to remove this block of code http://hg.openjdk.java.net/jdk/hs/file/eebf559c9e0d/src/hotspot/share/runtime/arguments.cpp#l1819

if COMPILER2ORJVMCI

// Shared spaces work fine with other GCs but causes bytecode rewriting // to be disabled, which hurts interpreter performance and decreases // server performance. When -server is specified, keep the default off // unless it is asked for. Future work: either add bytecode rewriting // at link time, or rewrite bytecodes in non-shared methods. if (isservercompilationmodevm() && !DumpSharedSpaces && !RequireSharedSpaces && (FLAGISDEFAULT(UseSharedSpaces) || !UseSharedSpaces)) { nosharedspaces("COMPILER2 default: -Xshare:auto | off, have to manually setup to on."); }

endif

Command-Line Flag -XX:+ExtensiveErrorReports

The command-line flag -XX:+ExtensiveErrorReports has been added to allow more extensive reporting of information related to a crash as reported in the hs_err<pid>.log file. Disabled by default in product builds, the flag can be turned on in environments where maximal information is desired - even if the resulting logs may be quite large and/or contain information that might be considered sensitive.

HotSpot Windows OS Detection Correctly Identifies Windows Server 2019

Prior to this fix, Windows Server 2019 was recognized as "Windows Server 2016", which produced incorrect values in the os.name system property and the hs_err_pid file.

Obsoleted -XX:+/-MonitorInUseLists

The VM Option -XX:-MonitorInUseLists is obsolete in JDK 12 and ignored. Use of this flag will result in a warning being issued. This option may be removed completely in a future release.

Added Additional TeliaSonera Root Certificate

The following root certificate have been added to the OpenJDK cacerts truststore: + TeliaSonera + teliasonerarootcav1

DN: CN=TeliaSonera Root CA v1, O=TeliaSonera

-groupname Option Added to keytool Key Pair Generation

A new -groupname option has been added to keytool -genkeypair so that a user can specify a named group when generating a key pair. For example, keytool -genkeypair -keyalg EC -groupname secp384r1 will generate an EC key pair by using the secp384r1 curve. Because there might be multiple curves with the same size, using the -groupname option is preferred over the -keysize option.

Customizing PKCS12 keystore Generation

New system and security properties have been added to enable users to customize the generation of PKCS #12 keystores. This includes algorithms and parameters for key protection, certificate protection, and MacData. The detailed explanation and possible values for these properties can be found in the "PKCS12 KeyStore properties" section of the java.security file.

Also, support for the following SHA-2 based HmacPBE algorithms has been added to the SunJCE provider: HmacPBESHA224, HmacPBESHA256, HmacPBESHA384, HmacPBESHA512, HmacPBESHA512/224, HmacPBESHA512/256

Deprecated Default Keytool -keyalg Value

The default -keyalg value for the -genkeypair and -genseckey commands of keytool have been deprecated. If a user has not explicitly specified a value for the -keyalg option a warning will be shown. An additional informational text will also be printed showing the algorithm(s) used by the newly generated entry. In a subsequent JDK release, the default key algorithm values will no longer be supported and the -keyalg option will be required.

disallow and allow Options for java.security.manager System Property

New "disallow" and "allow" token options have been added to the java.security.manager system property. In the JDK implementation, if the Java Virtual Machine starts with the system property java.security.manager set to "disallow", then the System.setSecurityManager method cannot be used to set a security manager and will throw an UnsupportedOperationException. The "disallow" option can improve run-time performance for applications that never set a security manager. For further details on the behavior of these options, see the class description of java.lang.SecurityManager.

Removal of GTE CyberTrust Global Root

The GTE CyberTrust Global Root certificate is expired and has been removed from the cacerts keystore: + alias name "gtecybertrustglobalca [jdk]"

Distinguished Name: CN=GTE CyberTrust Global Root, OU="GTE CyberTrust Solutions, Inc.", O=GTE Corporation, C=US

Added Entrust Root Certificates

The following root certificates have been added to the OpenJDK cacerts truststore: + Entrust + entrustrootcaec1

DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, 
       OU=(c) 2012 Entrust, Inc. - for authorized use only,
       CN=Entrust Root Certification Authority - EC1

• entrust2048ca

  DN: O=Entrust.net, OU=www.entrust.net/CPS_2048 incorp. by ref. (limits liab.), OU=(c) 1999 Entrust.net Limited, CN=Entrust.net Certification Authority (2048)

• entrustrootcag2

  DN: C=US, O=Entrust, Inc., OU=See www.entrust.net/legal-terms, OU=(c) 2009 Entrust, Inc. - for authorized use only, CN=Entrust Root Certification Authority - G2

• entrustevca

  DN: C=US, O=Entrust, Inc., OU=www.entrust.net/CPS is incorporated by reference, OU=(c) 2006 Entrust, Inc., CN=Entrust Root Certification Authority

• affirmtrustnetworkingca

  DN: C=US, O=AffirmTrust, CN=AffirmTrust Networking

• affirmtrustpremiumca

  DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium

• affirmtrustcommercialca

  DN: C=US, O=AffirmTrust, CN=AffirmTrust Commercial

• affirmtrustpremiumeccca

  DN: C=US, O=AffirmTrust, CN=AffirmTrust Premium ECC

New Java Flight Recorder (JFR) Security Events

Four new JFR events have been added to the security library area. These events are disabled by default and can be enabled via the JFR configuration files or via standard JFR options.

• jdk.SecurityPropertyModification

• Records Security.setProperty(String key, String value) method calls

• jdk.TLSHandshake

• Records TLS handshake activity. The event fields include:

  • Peer hostname
  • Peer port
  • TLS protocol version negotiated
  • TLS cipher suite negotiated
  • Certificate id of peer client

• jdk.X509Validation

• Records details of X.509 certificates negotiated in successful X.509 validation (chain of trust)

• jdk.X509Certificate

• Records details of X.509 Certificates. The event fields include:

  • Certificate algorithm
  • Certificate serial number
  • Certificate subject
  • Certificate issuer
  • Key type
  • Key length
  • Certificate id
  • Validity of certificate

Removal of AOL and Swisscom Root Certificates

The following root certificates have been removed from the cacerts truststore: + AOL + aolrootca1

DN: CN=America Online Root Certification Authority 1, O=America Online Inc., C=US

• aolrootca2

  DN: CN=America Online Root Certification Authority 2, O=America Online Inc., C=US

• Swisscom

• swisscomrootca2

  DN: CN=Swisscom Root CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch

Support New Japanese Era in java.time.chrono.JapaneseEra

The JapaneseEra class and its of(int), valueOf(String), and values() methods are clarified to accommodate future Japanese era additions, such as how the singleton instances are defined, what the associated integer era values are, etc.

JEP 335: Deprecate the Nashorn JavaScript Engine

Deprecate the Nashorn JavaScript script engine and APIs, and the jjs tool, with the intent to remove them in a future release (JEP 335).

The Nashorn JavaScript Engine implementation, the APIs and the jjs shell tool have been deprecated and might be removed in a future release. Code that uses classes and interfaces from jdk.nashorn.api.scripting and jdk.nashorn.api.tree packages will get a deprecation warning from javac.

The Nashorn engine (when used by javax.script API or jrunscript tool) as well as jjs shell tool will print a warning message about deprecation. To disable this runtime warning message, users can include the new Nashorn option, --no-deprecation-warning. This might be useful for compatibility scripts that depend on exact output (such as, to avoid the warning breaking their expected exact output).

Support for dns_canonicalize_hostname in krb5.conf

The dns_canonicalize_hostname flag in the krb5.conf configuration file is now supported by the JDK Kerberos implementation. When set to "true", a short hostname in a service principal name will be canonicalized to a fully qualified domain name if available. Otherwise, no canonicalization is performed. The default value is "true". This is also the behavior before JDK 12.

jdeps --print-module-deps Reports Transitive Dependences

jdeps --print-module-deps, --list-deps, and --list-reduce-deps options have been enhanced as follows.

1. By default, they perform transitive module dependence analysis on libraries on the class path and module path, both directly and indirectly, as required by the given input JAR files or classes. Previously, they only reported the modules required by the given input JAR files or classes. The --no-recursive option can be used to request non-transitive dependence analysis.

2. By default, they flag any missing dependency, i.e. not found from class path and module path, as an error. The --ignore-missing-deps option can be used to suppress missing dependence errors. Note that a custom image is created with the list of modules output by jdeps when using the --ignore-missing-deps option for a non-modular application. Such an application, running on the custom image, might fail at runtime when missing dependence errors are suppressed.

JEP 334: JVM Constants API

The new package java.lang.invoke.constant introduces an API to model nominal descriptions of class file and run-time artifacts, in particular constants that are loadable from the constant pool. It does so by defining a family of value-based symbolic reference (JVMS 5.1) types, capable of describing each kind of loadable constant. A symbolic reference describes a loadable constant in purely nominal form, separate from class loading or accessibility context. Some classes can act as their own symbolic references (e.g., String); for linkable constants a family of symbolic reference types has been added (ClassDesc, MethodTypeDesc, MethodHandleDesc, and DynamicConstantDesc) that contain the nominal information to describe these constants.

Support for Unicode 11

The JDK 12 release includes support for Unicode 11.0.0. Following the release of JDK 11, which supported Unicode 10.0.0, Unicode 11.0.0 introduced the following new features that are now included in JDK 12: - 684 new characters - 11 new blocks - 7 new scripts.

684 new characters that include important additions for the following: - 66 emoji characters
- Copyleft symbol - Half stars for rating systems - Additional astrological symbols - Xiangqi Chinese chess symbols

7 new scripts : - Hanifi Rohingya - Old Sogdian - Sogdian - Dogra - Gunjala Gondi - Makasar - Medefaidrin

11 new blocks that include 7 blocks for the new scripts listed above and 4 blocks for the following existing scripts: - Georgian Extended - Mayan Numerals - Indic Siyaq Numbers - Chess Symbols

Support for Compact Number Formatting

NumberFormat adds support for formatting a number in its compact form. Compact number formatting refers to the representation of a number in a short or human readable form. For example, in the en_US locale, 1000 can be formatted as "1K" and 1000000 can be formatted as "1M", depending upon the style specified by NumberFormat.Style. The compact number formats are defined by LDML's specification for Compact Number Formats. To obtain an instance, use one of the factory methods given by NumberFormat for compact number formatting. For example:

``` NumberFormat fmt = NumberFormat.getCompactNumberInstance(Locale.US, NumberFormat.Style.SHORT); String result = fmt.format(1000);

``` The example above results in "1K".

LDAPS Communication Failure

Application code using LDAPS with a socket connect timeout that is <= 0 ( the default value ), may encounter an exception when establishing the connection.

The top most frames from Exception stack traces of applications encountering such issues might resemble the following:

` javax.naming.ServiceUnavailableException: <server:port>; socket closed at com.sun.jndi.ldap.Connection.readReply(Unknown Source)<br /> at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ... `

Removal of finalize Method in java.util.ZipFile/Inflator/Deflator

The finalize method in java.util.ZipFile, java.util.Inflator, and java.util.Deflator was deprecated for removal in JDK 9 and its implementation was updated to be a no-op. The finalize method in java.util.ZipFile, java.util.Inflator, and java.util.Deflator has been removed in this release. Subclasses that override finalize in order to perform cleanup should be modified to use alternative cleanup mechanisms and to remove the overriding finalize method.

The removal of the finalize methods will expose Object.finalize to subclasses of ZipFile, Deflater, and Inflater. Compilation errors might occur on the override of finalize due to the change in declared exceptions. Object.finalize is now declared to throw java.lang.Throwable. Previously, only java.io.IOException was declared.

ChaCha20 and Poly1305 TLS Cipher Suites

New TLS cipher suites using the ChaCha20-Poly1305 algorithm have been added to JSSE. These cipher suites are enabled by default. The TLSCHACHA20POLY1305SHA256 cipher suite is available for TLS 1.3. The following cipher suites are available for TLS 1.2: - TLSECDHEECDSAWITHCHACHA20POLY1305SHA256 - TLSECDHERSAWITHCHACHA20POLY1305SHA256 - TLSDHERSAWITHCHACHA20POLY1305_SHA256

Refer to the "Java Secure Socket Extension (JSSE) Reference Guide" for details on these new TLS cipher suites.

Removed TLS v1 and v1.1 from SSLContext Required Algorithms

The requirement that all SE implementations must support TLSv1 and TLSv1.1 has been removed from the javax.net.ssl.SSLContext API and the Java Security Standard Algorithm Names specification.

supported_groups Extension Should Not be Present in ServerHello Handshake Message

While the supported_groups extension should not be present in ServerHello handshake messages, previous releases have ignored its presence, so that misconfigured servers could continue to function. JDK 11 currently throws an exception if this extension is sent in the ServerHello handshake message.

Disabled TLS anon and NULL Cipher Suites

The TLS anon (anonymous) and NULL cipher suites have been added to the jdk.tls.disabledAlgorithms security property and are now disabled by default.

Default SSL Session Cache Size Updated to 20480

The default SSL session cache size has been updated to 20480 in this JDK release

Distrust TLS Server Certificates Anchored by Symantec Root CAs

The JDK will stop trusting TLS Server certificates issued by Symantec, in line with similar plans recently announced by Google, Mozilla, Apple, and Microsoft. The list of affected certificates includes certificates branded as GeoTrust, Thawte, and VeriSign, which were managed by Symantec.

TLS Server certificates issued on or before April 16, 2019 will continue to be trusted until they expire. Certificates issued after that date will be rejected. See the DigiCert support page for information on how to replace your Symantec certificates with a DigiCert certificate (DigiCert took over validation and issuance for all Symantec Website Security SSL/TLS certificates on December 1, 2017).

An exception to this policy is that TLS Server certificates issued through two subordinate Certificate Authorities managed by Apple, and identified below, will continue to be trusted as long as they are issued on or before December 31, 2019.

The restrictions are enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below.

An application will receive an Exception with a message indicating the trust anchor is not trusted, ex:

"TLS Server certificate issued after 2019-04-16 and anchored by a distrusted legacy Symantec root CA: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US"

If necessary, and at your own risk, you can work around the restrictions by removing "SYMANTEC_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Symantec Root certificates included in the JDK:

If you have a TLS Server certificate issued by one of the CAs above, you should have received a message from DigiCert with information about replacing that certificate, free of charge.

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server if not yours.

Disabled All DES TLS Cipher Suites

DES-based TLS cipher suites are considered obsolete and should no longer be used. DES-based cipher suites have been deactivated by default in the SunJSSE implementation by adding the "DES" identifier to the jdk.tls.disabledAlgorithms security property. These cipher suites can be reactivated by removing "DES" from the jdk.tls.disabledAlgorithms security property in the java.security file or by dynamically calling the Security.setProperty() method. In both cases re-enabling DES must be followed by adding DES-based cipher suites to the enabled cipher suite list using the SSLSocket.setEnabledCipherSuites() or SSLEngine.setEnabledCipherSuites() methods.

Note that prior to this change, DES40_CBC (but not all DES) suites were disabled via the jdk.tls.disabledAlgorithms security property.

Change to X25519 and X448 Encoded Private Key Format

The encoded format of X25519 and X448 private keys has been corrected to use the standard format described in RFC 8410. This change affects any private key produced from the "X25519", "X448", or "XDH" services in the SunEC provider. The correct format is not compatible with the format used in previous JDK versions. It is recommended that existing incompatible keys in storage be replaced with newly-generated private keys.

Deprecated NSWindowStyleMaskTexturedBackground

After an upgrade of the macOS SDK used to build the JDK, the behavior of the apple.awt.brushMetalLook and textured Swing properties has changed. When these properties are set, the title of the frame is still visible. It is recommended that the apple.awt.transparentTitleBar property be set to true to make the title of the frame invisible again. The apple.awt.fullWindowContent property can also be used.

Please note that Textured window support was implemented by using the NSTexturedBackgroundWindowMask value of NSWindowStyleMask. However, this was deprecated in macOS 10.12 along with NSWindowStyleMaskTexturedBackground, which was deprecated in macOS 10.14.

For additional information, refer to the following documentation: - apple.awt.brushMetalLook: https://developer.apple.com/documentation/appkit/nstexturedbackgroundwindowmask?language=objc - apple.awt.transparentTitleBar: https://developer.apple.com/documentation/appkit/nswindow/1419167-titlebarappearstransparent?language=objc - apple.awt.fullWindowContent: https://developer.apple.com/documentation/appkit/nsfullsizecontentviewwindowmask

Removal of com.sun.awt.SecurityWarning Class

The com.sun.awt.SecurityWarning class was deprecated as forRemoval=true in JDK 11 (JDK-8205588). This class was unused in the JDK and has been removed in this release.

Removal of finalize Methods from FileInputStream and FileOutputStream

The finalize methods of FileInputStream and FileOutputStream were deprecated for removal in JDK 9. They have been removed in this release. Thejava.lang.ref.Cleaner has been implemented since JDK 9 as the primary mechanism to close file descriptors that are no longer reachable from FileInputStream and FileOutputStream. The recommended approach to close files is to explicitly call close or to use try-with-resources.

Disable the File Canonicalization Cache by Default

The file canonicalization cache has long-standing correctness issues; see JDK-7066948. For this reason, the cache is now disabled by default. It can be re-enabled by setting the sun.io.useCanonCaches system property. The cache was removed in JDK 21; see JDK-8309215.

ZGC: Concurrent Class Unloading

The Z Garbage Collector now supports class unloading. By unloading unused classes, data structures related to these classes can be freed, lowering the overall footprint of the application. Class unloading in ZGC happens concurrently, without stopping the execution of Java application threads, and has zero impact on GC pause times. This feature is enabled by default, but can be disabled by using the command line option -XX:-ClassUnloading.

Allocation of Old Generation of Java Heap on Alternate Memory Devices

This experimental feature in G1 and Parallel GC allows them to allocate the old generation of the Java heap on an alternative memory device such as NV-DIMM memory.

Operating systems today expose NV-DIMM memory devices through the file system. Examples are NTFS DAX mode and ext4 DAX mode. Memory-mapped files in these file systems bypass the file cache and provide a direct mapping of virtual memory to the physical memory on the device. The specification of a path to an NV-DIMM file system by using the flag -XX:AllocateOldGenAt=<path> enables this feature. There is no additional flag to enable this feature.

When enabled, young generation objects are placed in DRAM only while old generation objects are always allocated in NV-DIMM. At any given point, the collector guarantees that the total memory committed in DRAM and NV-DIMM memory is always less than the size of the heap as specified by -Xmx.

The current implementation pre-allocates the full Java heap size in the NV-DIMM file system to avoid problems with dynamic generation sizing. Users need to make sure there is enough free space on the NV-DIMM file system.

When enabled, the VM also limits the maximum size of the young generation based on available DRAM, although it is recommended that users set the maximum size of the young generation explicitly.

For example, if the VM is run with -Xmx756g on a system with 32GB DRAM and 1024GB NV-DIMM memory, the collector will limit the young generation size based on following calculation: 1. No -XX:MaxNewSize or -Xmn is specified: the maximum young generation size is set to 80% of available memory (25.6GB). 2. -XX:MaxNewSize or -Xmn is specified: the maximum young generation size is capped at 80% of available memory (25.6GB) regardless of the amount specified. 3. Users can use -XX:MaxRAM to let the VM know how much DRAM is available for use. If specified, maximum young gen size is set to 80% of the value in MaxRAM. 4. Users can specify the percentage of DRAM to use (instead of the default 80%) for young generation with -XX:MaxRAMPercentage.

Enabling logging with the logging option gc+ergo=info will print the maximum young generation size at startup.

Epsilon GC handled checked array stores incorrectly

Epsilon GC may have violated the specification requirements by accepting the type-incompatible store into the array, instead of throwing the ArrayStoreException. This is now handled correctly, both in this release, and associated backports. Users are advised to upgrade as soon as possible.

G1 May Uncommit Memory During Marking Cycle

By default, G1 may now give back Java heap memory to the operating system during any concurrent mark cycle. G1 will respect default Java heap sizing policies at that time.

This change improves memory usage of the Java process if the application does not need all memory.

This behavior may be disabled in accordance with default heap sizing policies by setting minimum Java heap size to maximum Java heap size via the -Xms option.