Java 11 Guidelines
The GigaSpaces Platform and GigaSpaces 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.
Java Distributions
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.
Memory Footprint
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.
Performance
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:
-XX:+UseParallelGC - G1 GC:
-XX:+UseG1GC
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.
Security
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 GigaSpaces Platform or the GigaSpaces 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: -Dcom.gs.lrmi.filter.security.protocol=TLS, specify -Dcom.gs.lrmi.filter.security.protocol=TLSv1.2.
Third-Party Support for Java 11
Spring
Officially, Spring supports Java 11 starting from version 5.1. The GigaSpaces Platform and GigaSpaces data grid currently support Spring version 4.x and are packaged with the latest 4.3.x Spring release. Internal testing of GigaSpaces products with Spring version 5.1 has been performed and no issues were noted. Spring 5.x support is planned for a future release.
Hibernate
The GigaSpaces-Hibernate integration is currently based on Hibernate
Spark
The GigaSpaces Platform is currently packaged with Spark version 2.3.2, which is based on Scala version 2.11 that does not support Java 11. The latest Spark 2.4 release includes experimental support for Scala 2.12 and Java 11, but as the term suggests it not yet completely certified and the ecosystem has only partial support for this combination.
Spark 2.4 support is planned for a future release of the GigaSpaces Platform, at which point the GigaSpaces product will include the same level experimental support of Scala 2.12 and Java 11 as is provided with Spark 2.4.
Windows
GigaSpaces GigaSpaces, XAP.NET and GigaSpaces Platform use a dependency called Sigar, which does not support Java 11 on Windows environments. This dependency is optional and can be removed; it mainly affects resource monitoring. This issue is scheduled for improvement in a future release of GigaSpaces products.
