VMware Tanzu GemFire is supported on a variety of platforms.
Note: Running Tanzu GemFire clusters with a mix of different platforms has not been tested. We recommend that you use a consistent platform on all machines in your cluster.
All platforms listed as deprecated may be removed in a future release of the product.
These Tanzu GemFire 9.15 platforms provide support for production systems:
These cloud platforms are supported for Tanzu GemFire 9.15:
These Tanzu GemFire 9.15 platforms provide support for development systems:
This version of Tanzu GemFire requires Java 8 release 121 or a more recent version 8 update. The same versions are supported with OpenJDK (HotSpot).
Tanzu GemFire is also compatible with Open JDK 11 and JDK 17.
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.
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:
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.
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
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:
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.
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
gfshautomatically supplies these options whenever it launches a locator or server process.
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:
This example allows Tanzu GemFire to inspect
BigDecimal and other types declared in the
java.math package in the
Because the JDK loads Tanzu 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 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 @path/to/my-argument-file ...
The Tanzu 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 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
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 does not include the CMS garbage collector. The default garbage collector is now G1. See Managing Heap Memory for details about configuring Tanzu GemFire's use of the garbage collector.