Java Support
This version of Geode requires Java 8 release 121 or a more recent version 8 update. The same versions are supported with OpenJDK (HotSpot).
Geode is also compatible with Open JDK 11 and JDK 17.
The Geode product download does not include Java.
Download and install a supported JRE or JDK on each system running Geode.
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 Geode
How JDK 17 Encapsulation Affects Geode
Beginning with Java 17, the JVM strongly enforces the encapsulation policies introduced in Java 9 by the Java Platform Module System.
Several Geode 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, Geode, 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 Geode for ways to identify what access Geode needs, and Granting Access to Encapsulated Types for ways to grant that access.
Access Required by Geode
Geode may require reflective access to the types used in your application data.
If Geode 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 Geode features that you use, Geode 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, Geode 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, Geode may require explicit access to that type.
Geode can automatically access types declared in packages loaded from the classpath.
Additional Access Required by All Geode Processes
Geode 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 Geode:
--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 Geode 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 Geode. For example:
--add-opens=java.base/java.math=ALL-UNNAMED
This example allows Geode to inspect BigDecimal
and other types declared in the java.math
package in the java.base
module.
Because the JDK loads Geode 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 Geode 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 Geode 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 Geode clients and other applications with Geode functionality:
java @path_to_product/config/open-all-jdk-packages-linux-openjdk-17 ...
When launching Geode 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
Java 17 does not include the CMS garbage collector. The default garbage collector is now G1. See Managing Heap Memory for details about configuring Geode’s use of the garbage collector.