How Upgrading from JDK 8 to JDK 11 Boosts Performance and Unlocks New Java Features

Background

The author records the practical process of upgrading from JDK 8 to JDK 11, describing why the upgrade is needed.

Performance – JDK 11’s G1 GC offers much higher throughput and lower memory footprint compared with JDK 8.

Version compatibility – Spring Boot 2.7.x and later no longer support Java 8; many middleware components have dropped JDK 8 support.

Industry trend – JDK 11 (LTS) is now the mainstream choice in the Java community.

Pre‑upgrade Considerations

JDK 11 introduces many breaking changes; complex codebases may face compatibility problems such as third‑party libraries not supporting the new version.

Some APIs deprecated in Java 8 (e.g., parts of sun.misc.Unsafe) have been removed, requiring code modifications.

Extensive validation is required because many issues only surface at runtime.

Upgrade Process

Steps include downloading the appropriate JDK 11 distribution, configuring the IDE to use JDK 11, and updating the build files.

<maven.compiler.target>11</maven.compiler.target>
<maven.compiler.source>11</maven.compiler.source>
<java.version>11</java.version>
<spring-boot.version>2.1.6.RELEASE</spring-boot.version>
<lombok.version>1.18.12</lombok.version>

Minimum versions for key components:

spring‑boot: 2.1.x (supports JDK 11)

spring: 5.1.x

idea: 2018.2

maven: 3.5.0

lombok: 1.18.x

netty: ≥ 4.1.33.Final (otherwise off‑heap memory grows)

apache‑common‑lang3: 3.12.0

Common Issues and Solutions

Deprecated auto‑configuration – Spring Boot 2.0+ removed the global security auto‑configuration; configure Actuator security manually.

Missing dependencies – Add explicit versions for removed modules (e.g., javax.xml.soap, jaxb, hibernate-validator).

Remote debugging – JDK 9+ binds JDWP to localhost by default; set address=*:8000 or 0.0.0.0:8000 to enable remote debugging.

Maven compiler plugin – Upgrade to the latest version and set

<maven.compiler.source>11</maven.compiler.source>

and

<maven.compiler.target>11</maven.compiler.target>

.

Spring / Spring Boot versions – Spring 5.1+ and Spring Boot 2.1+ support JDK 11; upgrade to the newest releases.

Netty – Upgrade to ≥ 4.1.33.Final to avoid excessive off‑heap memory usage.

Lombok – Use the latest Lombok version (e.g., 1.18.24) after moving to JDK 11.

Security starter – Use the 2.x series of security-spring-boot-starter for Spring Boot 2.

Application Deployment

Switch to the G1 garbage collector and tune JVM options:

# Use G1 GC
SERVICE_OPTS="${SERVICE_OPTS} -XX:+UseG1GC -XX:+UseVtableBasedCHA -XX:+UseCompactObjectHeaders"
SERVICE_OPTS="${SERVICE_OPTS} -XX:G1HeapRegionSize=8m"
SERVICE_OPTS="${SERVICE_OPTS} -XX:G1HeapWastePercent=2"
SERVICE_OPTS="${SERVICE_OPTS} -Xlog:gc*:/home/admin/logs/gc.log:time"
# Adjust processor count if needed
if [ -n "$AJDK_MAX_PROCESSORS_LIMIT" ]; then
    SERVICE_OPTS="${SERVICE_OPTS} -XX:ActiveProcessorCount=$AJDK_MAX_PROCESSORS_LIMIT"
fi

GC Tuning

G1 is largely self‑tuning, but the following parameters may be adjusted for specific workloads: -XX:MaxGCPauseMillis=N – Target pause time (default 200 ms). Setting it too low can increase GC frequency. -XX:InitiatingHeapOccupancyPercent=N and -XX:-G1UseAdaptiveIHOP – Control when mixed GC starts; useful for large heaps. -XX:G1HeapRegionSize – Typically 8 MiB–32 MiB for e‑commerce workloads. -XX:G1HeapWastePercent – Default 5 %; reducing to 2 % can improve throughput for large heaps. -XX:G1MixedGCCountTarget – Default 8; increasing it spreads mixed‑GC work over more cycles.

Upgrade Effects

Performance measurements show significant improvements after switching to JDK 11 + G1:

GC pause times for Young GC dropped from 7.4 ms (JDK 8 + CMS) to 3.74 ms (JDK 11 + G1), a 49.5 % reduction, while overall throughput increased by about 50 %.

JDK 11 New Features

String enhancements

String str = " i am lzc ";
bool isBlank = str.isBlank(); // false
bool isEmpty = str.isEmpty(); // false
String stripped = str.strip(); // "i am lzc"
String repeated = str.repeat(2); // " i am lzc  i am lzc "
long lineCount = str.lines().count(); // 1

Files API enhancements

Path filePath = Files.writeString(Path.of("/temp/a.txt"), "Sample text");
String content = Files.readString(filePath);
System.out.println(content.equals("Sample text")); // true

Stream API enhancements

long count = Stream.ofNullable(null).count(); // 0
List<Integer> dropped = Stream.of(1,2,3,2,1).dropWhile(n -> n < 3).toList(); // [3,2,1]
List<Integer> taken = Stream.of(1,2,3,2,1).takeWhile(n -> n < 3).toList(); // [1,2]

Collection factory methods

List<Integer> list = List.of(1,3,5,7);
List<Integer> copy = List.copyOf(list);
Map<Integer,String> map = Map.of(1,"a",2,"b",3,"c");
Map<Integer,String> mapCopy = Map.copyOf(map);

Optional enhancements

Object v = Optional.ofNullable(null).orElseThrow(); // throws NoSuchElementException
Optional.ofNullable(null).ifPresentOrElse(System.out::println, () -> System.out.println("Data missing"));
Object fallback = Optional.ofNullable(null).or(() -> Optional.of("fallback")).get(); // "fallback"
System.out.println(fallback);

HttpClient (standard)

HttpClient client = HttpClient.newHttpClient();
HttpRequest request = HttpRequest.newBuilder().uri(URI.create(uri)).build();
client.sendAsync(request, HttpResponse.BodyHandlers.ofString())
      .thenApply(HttpResponse::body)
      .thenAccept(System.out::println)
      .join();
HttpResponse<String> response = client.send(request, HttpResponse.BodyHandlers.ofString());
System.out.println(response.body());