Why You Should Upgrade to Apache Geode 2.0 – Moving Beyond JDK 8

Geode Overview

Apache Geode is a distributed in‑memory data management platform (In‑Memory Data Grid) that stores hot data in RAM across a cluster, providing millisecond‑level latency, automatic replica failover, partitioning, replication, cross‑datacenter synchronization, and server‑side compute.

Why upgrade to 2.0

The Java ecosystem has moved to Jakarta EE and JDK 17+. Geode 1.x remains on JDK 8/11 and javax.* APIs, causing incompatibility with modern Spring Boot 3, Tomcat 10, Jetty 12, and missing security patches. The community released Geode 2.0.0 (January 2026) to align with current standards.

Key changes in Geode 2.0

1. Minimum JDK 17

Geode 2.0 requires JDK 17 (LTS). Applications on JDK 8/11 must upgrade before using Geode 2.0.

2. Migration to Jakarta EE 10

All Java EE packages are renamed from javax.* to jakarta.*. This affects Servlets, JTA, JAXB, annotations, etc., and involves changes in about 170 files. Example import change is shown below.

3. Spring stack upgrade

Spring Framework and Spring Security are upgraded to 6.x; Spring Boot dependencies move to 3.x. The GFSH command‑line shell is upgraded from Spring Shell 1.x to 3.x, changing annotation @CliCommand to @ShellMethod.

4. Security and HTTP improvements

Unsafe reflection is removed, JEP 290 deserialization filters are added for HTTP session protection, and the HTTP client is upgraded to Apache HttpComponents 5.x with HTTP/2 support. The build system is upgraded to Gradle 7.3.3.

Getting started

Maven dependency

<dependency>
  <groupId>org.apache.geode</groupId>
  <artifactId>geode-core</artifactId>
  <version>2.0.0</version>
</dependency>

Gradle dependency

dependencies {
  implementation "org.apache.geode:geode-core:2.0.0"
}

Start a minimal cluster with GFSH

gfsh
start locator --name=locator1 --port=10334
start server --name=server1 --server-port=40404
create region --name=orders --type=PARTITION

Region type PARTITION distributes keys; alternatives PARTITION_REDUNDANT or REPLICATE provide redundancy.

Client example (Java)

import org.apache.geode.cache.Region;
import org.apache.geode.cache.client.ClientCache;
import org.apache.geode.cache.client.ClientCacheFactory;
import org.apache.geode.cache.client.ClientRegionShortcut;

public class OrderCacheDemo {
  public static void main(String[] args) {
    ClientCache cache = new ClientCacheFactory()
        .addPoolLocator("127.0.0.1", 10334)
        .create();
    Region<String, String> orders = cache
        .<String, String>createClientRegionFactory(ClientRegionShortcut.PROXY)
        .create("orders");
    orders.put("order-1001", "{\"sku\":\"SKU-88\",\"amount\":199.00}");
    String json = orders.get("order-1001");
    System.out.println("Read from Geode: " + json);
    cache.close();
  }
}

PROXY

means data resides on servers; CACHING_PROXY adds a near cache on the client.

Package migration

Replace all javax.* imports with jakarta.*. Example:

// Geode 1.x
import javax.servlet.http.HttpSession;
import javax.transaction.UserTransaction;

// Geode 2.0
import jakarta.servlet.http.HttpSession;
import jakarta.transaction.UserTransaction;

IDE global replace of javax.servlet → jakarta.servlet helps, but third‑party libraries must also support Jakarta, otherwise ClassNotFoundException occurs.

Upgrade checklist and pitfalls

Upgrade JDK first – using Geode 2.0 on JDK 8/11 will fail.

Do not mix javax and jakarta packages – leads to ClassNotFoundException.

Update custom GFSH commands – annotation changes required for Shell 3.x.

Test on a staging cluster – both rolling and stop‑the‑world upgrades are supported; choose based on downtime tolerance.

After the initial GA (2.0.0), maintenance releases 2.0.1, 2.0.2, etc., contain security fixes. Deploy the latest 2.0.x version.