Java Support

VMware Tanzu 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.

JDK	Recommended Version	Minimum Version
8	latest	u361
11	latest	11.0.18
17	latest	17.0.6

The Tanzu GemFire product download does not include Java. Download and install a supported JRE or JDK on each system running Tanzu 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.

Java Modules and Tanzu GemFire

How JDK 17 Encapsulation Affects Tanzu GemFire

Beginning with Java 17, the JVM strongly enforces the encapsulation policies introduced in Java 9 by the Java Platform Module System.

Several Tanzu 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, Tanzu GemFire, by default, cannot inspect the following encapsulated types and fields:

The private and protected types declared in named modules.
The private and protected fields of types declared in named modules.

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 Tanzu GemFire for ways to identify what access Tanzu GemFire needs, and Granting Access to Encapsulated Types for ways to grant that access.

Access Required by Tanzu GemFire

Tanzu GemFire may require reflective access to the types used in your application data.

If Tanzu 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

Access to the Types Used in Application Data

Depending on the Tanzu GemFire features that you use, Tanzu GemFire may require reflective access to the types used in your application data. This includes:

The types that define your application data.
The types to which your application data holds a reference, whether directly or indirectly.

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, Tanzu 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, Tanzu GemFire may require explicit access to that type.

Tanzu GemFire can automatically access types declared in packages loaded from the classpath.

Additional Access Required by All Tanzu GemFire Processes

Tanzu 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 Tanzu 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

Note: gfsh automatically supplies these options whenever it launches a locator or server process.

Granting Access to Encapsulated Types

Opening Specific Packages

To give Tanzu 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 Tanzu GemFire. For example:

--add-opens=java.base/java.math=ALL-UNNAMED

This example allows Tanzu GemFire to inspect BigDecimal and other types declared in the java.math package in the java.base module.

Because the JDK loads Tanzu GemFire code into an unnamed module, the --add-opens option must open the package to ALL-UNNAMED.

Using an Argument File

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 Tanzu 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 command:

java @path/to/my-argument-file ...

Opening All JDK Packages

The Tanzu GemFire distribution includes an argument file that opens every package in the Linux version of OpenJDK 17: path_to_product/config/open-all-jdk-packages-linux-openjdk-17.

Use the JDK 17 argument file as follows:

When launching Tanzu GemFire clients and other applications with Tanzu GemFire functionality:
```
java @path_to_product/config/open-all-jdk-packages-linux-openjdk-17 ...
```

When launching Tanzu GemFire members with gfsh, add the argument file as a --J option:

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.

Java 17 and Garbage Collection

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.

The gfsh 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.