GemFire v10 is certified for use with JDK 8, JDK 11 and JDK 17. Starting with version 10.0, JDK 11 is the preferred JDK version.
The GemFire product download does not include Java. Download and install a supported JRE or JDK on each system running GemFire. VMware recommends the installation of a full JDK (and not just a JRE) to obtain better performance with
gfsh status and
gfsh stop commands.
The IBM SDK, Java Technology Edition, Version 8 is supported for application clients only. Some client region eviction configurations such as
HEAP_LRU are known to not function properly with this SDK.
Beginning with Java 17, the JVM strongly enforces the encapsulation policies introduced in Java 9 by the Java Platform Module System.
Several GemFire features, such as serialization and eviction, use deep reflection to inspect the Java objects used as keys and values. In Java 17, this deep reflection requires that the object’s type be made explicitly available for reflection.
By default, each type declared in a named module is available for reflection only if the declaring module opens the type’s package.
As a result, GemFire, by default, cannot inspect the following encapsulated types and fields:
In Java 17, every type defined by the JDK is declared in a named module, and none are opened for reflection by any code outside of the JDK. Therefore, any encapsulated type or field defined by the JDK is, by default, unavailable for reflection.
See Access Required by GemFire for ways to identify what access GemFire needs, and Granting Access to Encapsulated Types for ways to grant that access.
GemFire may require reflective access to the types used in your application data.
If GemFire does not have the access it requires, it throws an exception similar to the following:
java.lang.reflect.InaccessibleObjectException: Unable to make field private final java.math.BigInteger java.math.BigDecimal.intVal accessible: module java.base does not "opens java.math" to unnamed module @23a5fd2
Depending on the GemFire features that you use, GemFire may require reflective access to the types used in your application data. This includes:
If any object of your application data is represented by a type declared in a named module, or holds a reference (directly or indirectly) to a type declared in a named module, GemFire may require explicit access to that type.
Note: Every type defined by the JDK is declared in a named module. Therefore, if any object of your application data is represented by a type defined by the JDK, or holds a reference (directly or indirectly) to a type defined by the JDK, GemFire may require explicit access to that type.
GemFire can automatically access types declared in packages loaded from the classpath.
GemFire always requires access to certain JDK packages, regardless of the types of objects used by your application. The following options must always be included when launching locators and servers, and when launching clients and other applications that depend on GemFire:
--add-exports=java.base/sun.nio.ch=ALL-UNNAMED --add-exports=java.management/com.sun.jmx.remote.security=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.nio=ALL-UNNAMED --add-opens=jdk.management/com.sun.management.internal=ALL-UNNAMED
gfsh automatically supplies these options whenever it launches a locator or server process.
To give GemFire access to the types in a specific package, use the
--add-opens command line option when launching a locator, server, client, or other application that uses GemFire. For example:
This example allows GemFire to inspect
BigDecimal and other types declared in the
java.math package in the
Because the JDK loads GemFire code into an unnamed module, the
--add-opens option must open the package to
Starting with Java 9, the
java command accepts argument files as an option. The
java command treats the content of the argument file as arguments for the JVM.
If you must use numerous JVM options to give GemFire the access it needs, you can combine the arguments into an argument file. For example:
--add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.base/java.time=ALL-UNNAMED --add-opens=java.base/java.time.chrono=ALL-UNNAMED --add-opens=java.base/java.time.format=ALL-UNNAMED --add-opens=java.base/java.time.temporal=ALL-UNNAMED --add-opens=java.base/java.time.zone=ALL-UNNAMED
To use an argument file, add the
@ prefix to identify your argument file to the
java @path/to/my-argument-file ...
The GemFire distribution includes an argument file that opens every package in the Linux version of OpenJDK 17:
Use the JDK 17 argument file as follows:
When launching GemFire clients and other applications with GemFire functionality:
java @path_to_product/config/open-all-jdk-packages-linux-openjdk-17 ...
When launching GemFire members with
gfsh, add the argument file as a
start locator --J=@path_to_product/config/open-all-jdk-packages-linux-openjdk-17 ... start server --J=@path_to_product/config/open-all-jdk-packages-linux-openjdk-17 ...
If you use a different JDK, copy and edit this file to add or remove packages to match your JDK.
VMware recommends using the Z garbage collector (ZGC) on Java 17. The G1 garbage collector, which Java 17 enables by default, is incompatible with GemFire’s heap LRU eviction feature.
start locator and
start server commands now enable ZGC by default on Java 17.
On a 64-bit JVM with a heap size less than 32 GB, switching from CMS or G1 to ZGC may increase the cache’s heap usage by up to 80%. The magnitude of this impact is highly dependent on the nature of your cached data.
On a 64-bit JVM with a heap size 32 GB or larger, switching from CMS or G1 to ZGC does not increase the cache’s heap usage.
On Linux, a JVM using ZGC may report a resident set size three times the actual memory usage.
For details about configuring Tanzu GemFire’s use of the garbage collector, see Managing Heap Memory.