Java 11 Guidelines
The InsightEdge Platform and XAP data grid support Java 11 starting from release 14.0.1. We strongly recommend reviewing the provided guidelines so you can fine-tune your Java implementation to achieve optimal system behavior and performance for applications based on GigaSpaces products.
Oracle has made a number of significant changes to their terms and conditions regarding Java 11 usage and support, and have also aligned their releases with OpenJDK. Starting from Java 11, GigaSpaces products are tested on OpenJDK, which is the de facto baseline for all popular JDK distributions on the market.
Modules and Classpath
The JPMS (Java Platform Module System) was introduced in Java 9. JPMS is a modern alternative to the previous modularity architecture based on JARs and classpath. However, JPMS is still fairly new and adoption in the ecosystem is slow. As such, classpath is still fully supported and not deprecated in Java 11. GigaSpaces products currently continue to use the classpath system.
Additionally, as part of remodeling the Java code and attempting to reduce its size and complexity, some Java EE technologies have been excluded from the standard Java package and are instead available as independent modules. Applications that use these modules can include the relevant ones explicitly, instead of the Java distribution implicitly containing all of them. GigaSpaces products use some of those dependencies, which have been packaged under
$GS_HOME/lib/platform/javax and are automatically included in the classpath.
Starting from Java 9, string implementation has been enhanced to use less memory in common use cases (see JEP 254). In a nutshell, in earlier Java versions each character in the string used at least two bytes, whereas from Java 9 and up common characters use only a single byte. This means that most strings consume ~50% less RAM in Java 11 environments, which may be significant for applications storing a lot of strings in the Space.
Starting from Java 9, the default garbage collector (GC) was changed from Parallel GC to G1 (see JEP 248). This change has performance implications, as described in the JEP motivation:
“Limiting GC pause times is, in general, more important than maximizing throughput. Switching to a low-pause collector such as G1 should provide a better overall experience, for most users, than a throughput-oriented collector such as the Parallel GC, which is currently the default.”
In other words, the Parallel GC is optimized for throughput at the expense of longer GC pauses, whereas the new default G1 GC is optimized for shorter GC pauses at the expense of lower throughput.
GigaSpaces benchmarking confirms this assertion. We evaluated GigaSpaces products with the following Java configurations and results:
- Java 11 and no GC configuration: throughput is lower.
- Java 11 and Parallel GC: throughput is the same as in systems using Java 8.
- Java 8 and G1 GC: throughput is the same as in systems using Java 11 with the default GC.
Use the following Java options to explicitly set a garbage collector:
- Parallel GC:
- G1 GC:
For more information about garbage collection in Java-based systems, see Oracle’s Garbage Collection Tuning Guide for Java 11.
Conclusion: When upgrading to Java 11, it is important to be aware of the new default GC mechanism, and to choose the one that best serves your application requirements. If your configuration already explicitly sets the GC mechanism, this GC will be the one used with Java 11.
Support for TLS 1.3 was added in Java 11. This version of TLS is not directly compatible with previous TLS versions, and is currently not supported in the InsightEdge Platform or the XAP data grid. When configuring TLS usage for GigaSpaces products using the
com.gs.lrmi.filter.security.protocol system property, the default is to choose the latest TLS available. In Java 11 this is TLS 1.3 and it will fail. To prevent this from happening, explicitly specify the requested TLS version, such as “TLSv1.2”.
For example, instead of:
Third-Party Support for Java 11
The InsightEdge Platform is currently packaged with Spark version 2.4.0, which is based on Scala version 2.11 that includes experimental support for Scala 2.12 and Java 11. As the term suggests, it not yet completely certified and the ecosystem has only partial support for this combination.