How do I understand the evolution of Java from Java 8 to Java 25?

Understanding Java’s Evolution from Java 8 to Java 25

A good way to understand Java’s evolution from Java 8 to Java 25 is to view it in phases:

  1. Java 8 established modern Java’s functional-programming foundation.
  2. Java 9–11 reshaped the platform and release model.
  3. Java 12–17 modernized the language with records, pattern matching, text blocks, and sealed classes.
  4. Java 18–21 improved concurrency, APIs, and developer ergonomics.
  5. Java 22–25 continue the move toward simpler, safer, more expressive Java.

1. Java 8: The Baseline of Modern Java

Java 8, released in 2014, is often considered the beginning of “modern Java.”

Major features:

  • Lambda expressions
  • Functional interfaces
  • Stream API
  • Default methods in interfaces
  • Optional
  • New Date and Time API
  • CompletableFuture
  • Method references

Example:

List<String> names = List.of("Alice", "Bob", "Charlie");

List<String> filtered = names.stream()
        .filter(name -> name.startsWith("A"))
        .toList();

Java 8 changed Java from being mostly object-oriented and imperative to supporting a much more functional style.


2. Java 9–11: Platform Modernization

Java 9

Java 9 introduced one of the largest structural changes in Java’s history:

  • Java Platform Module System, also called JPMS or Project Jigsaw
  • JShell
  • Collection factory methods
  • Private methods in interfaces
  • Improved Stream API

Example:

List<String> names = List.of("Alice", "Bob");
Set<Integer> numbers = Set.of(1, 2, 3);
Map<String, Integer> scores = Map.of("Alice", 10, "Bob", 20);

The module system allowed applications and libraries to define explicit dependencies:

module com.example.app {
    requires java.sql;
    exports com.example.app.api;
}

Java 10

Java 10 introduced:

  • Local-variable type inference with var
  • Application Class-Data Sharing improvements
  • Garbage collector interface improvements

Example:

var message = "Hello, Java";
var count = 42;

Important: var does not make Java dynamically typed. The type is still determined at compile time.

Java 11

Java 11 was a major LTS release.

Notable features:

  • HTTP Client API standardized
  • String utility methods
  • var in lambda parameters
  • Single-file source-code execution
  • Removal of several Java EE and CORBA modules from the JDK

Example:

var client = java.net.http.HttpClient.newHttpClient();

var request = java.net.http.HttpRequest.newBuilder()
        .uri(java.net.URI.create("https://example.com"))
        .build();

var response = client.send(
        request,
        java.net.http.HttpResponse.BodyHandlers.ofString()
);

3. Java 12–17: Language Expressiveness

This period brought many language features that made Java more concise and expressive.

Switch Expressions

Standardized in Java 14.

String result = switch (status) {
    case 200 -> "OK";
    case 404 -> "Not Found";
    case 500 -> "Server Error";
    default -> "Unknown";
};

This made switch usable as an expression and reduced accidental fall-through bugs.


Text Blocks

Standardized in Java 15.

String json = """
        {
          "name": "Alice",
          "active": true
        }
        """;

Text blocks made multiline strings much easier to write, especially for JSON, SQL, HTML, and test data.


Records

Standardized in Java 16.

public record User(Long id, String name, String email) {
}

A record automatically provides:

  • Constructor
  • Accessor methods
  • equals
  • hashCode
  • toString

Records are ideal for immutable data carriers, DTOs, API responses, and value-like objects.


Pattern Matching for instanceof

Standardized in Java 16.

Before:

if (obj instanceof String) {
    String text = (String) obj;
    System.out.println(text.toUpperCase());
}

After:

if (obj instanceof String text) {
    System.out.println(text.toUpperCase());
}

This reduces boilerplate and makes type checks safer.


Sealed Classes

Standardized in Java 17.

public sealed interface Payment permits CardPayment, CashPayment {
}

public final class CardPayment implements Payment {
}

public final class CashPayment implements Payment {
}

Sealed classes let you restrict which classes can extend or implement a type. This is useful for domain modeling, state machines, and exhaustive pattern matching.

Java 17 is also an LTS release and became a major upgrade target for many Java 8 and Java 11 applications.


4. Java 18–21: Runtime, Concurrency, and API Improvements

Java 18

Notable changes:

  • UTF-8 became the default charset
  • Simple web server command-line tool
  • Code snippets in Java API documentation

Java 19–20

These releases continued incubating and previewing major platform improvements, especially around:

  • Virtual threads
  • Structured concurrency
  • Pattern matching
  • Foreign Function & Memory API

Java 21

Java 21 is another major LTS release.

Important features:

  • Virtual threads
  • Sequenced collections
  • Pattern matching for switch
  • Record patterns
  • String templates as preview
  • Unnamed patterns and variables as preview
  • Structured concurrency as preview
  • Scoped values as preview

Virtual Threads

Virtual threads are one of the biggest Java platform changes since lambdas.

They make thread-per-request programming scalable:

try (var executor = java.util.concurrent.Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        System.out.println("Running in a virtual thread");
    });
}

Virtual threads are especially important for server-side applications, web services, database calls, and blocking I/O workloads.

They do not automatically make CPU-heavy code faster, but they greatly improve scalability for many I/O-bound applications.


Sequenced Collections

Java 21 introduced interfaces for collections with a defined encounter order:

  • SequencedCollection
  • SequencedSet
  • SequencedMap

Example:

SequencedCollection<String> names = new ArrayList<>();
names.add("Alice");
names.add("Bob");

String first = names.getFirst();
String last = names.getLast();

This regularized APIs for getting first and last elements across ordered collections.


5. Java 22–25: Continued Simplification and Modernization

Java 22, 23, 24, and 25 continue the six-month release cadence, building on earlier preview and incubator features.

Important ongoing areas include:

  • More powerful pattern matching
  • Improvements to unnamed variables and patterns
  • Class-file API work
  • Foreign Function & Memory API maturation
  • Stream gatherers
  • Structured concurrency
  • Scoped values
  • Better startup, monitoring, and runtime performance
  • More convenient entry points for beginner-friendly Java programs

The broad direction is clear: Java is becoming more concise, more expressive, better suited for cloud-native systems, and more approachable without abandoning its strong compatibility model.


LTS Releases Matter

From Java 8 to Java 25, the most important versions for many teams are the LTS releases:

Version Why It Matters
Java 8 Functional programming baseline; still widely used historically
Java 11 First major post-Java-8 LTS; HTTP Client; modular-era cleanup
Java 17 Records, sealed classes, pattern matching, strong modernization point
Java 21 Virtual threads, sequenced collections, advanced pattern matching
Java 25 Next LTS line after Java 21

If you are maintaining enterprise applications, understanding the path 8 → 11 → 17 → 21 → 25 is usually more useful than studying every interim version equally.


Big Themes Across Java 8 to Java 25

1. Less Boilerplate

Java has steadily reduced ceremony:

  • Lambdas
  • var
  • Records
  • Pattern matching
  • Switch expressions
  • Text blocks
  • Compact source files and simpler entry points

Example progression:

public record Customer(String name, String email) {
}

Compared to pre-record Java, this can replace dozens of lines of boilerplate.


2. Better Domain Modeling

Modern Java gives you stronger modeling tools:

  • Records for immutable data
  • Sealed classes for restricted hierarchies
  • Pattern matching for safe decomposition
  • Enhanced switch for exhaustive handling

Example:

sealed interface OrderStatus permits Pending, Paid, Cancelled {
}

record Pending() implements OrderStatus {
}

record Paid(String transactionId) implements OrderStatus {
}

record Cancelled(String reason) implements OrderStatus {
}

This style is useful when modeling finite states or domain events.


3. Better Concurrency

Java 8 gave developers:

  • CompletableFuture
  • Parallel streams

Java 21+ adds:

  • Virtual threads
  • Structured concurrency
  • Scoped values

The shift is from complex asynchronous programming toward simpler blocking-style code that scales better.


4. Better APIs

Across these releases, Java improved many everyday APIs:

  • Collections
  • Strings
  • Files
  • HTTP
  • Date/time
  • Random number generation
  • Foreign memory access
  • Cryptography
  • Monitoring and diagnostics

Examples:

boolean blank = "   ".isBlank();
String repeated = "Java ".repeat(3);
List<String> lines = "a\nb\nc".lines().toList();

5. Strong Compatibility, but Not No Change

Java is famous for backward compatibility. Most old Java code still runs on newer JVMs.

However, migration can still involve work:

  • Removed Java EE modules after Java 8
  • Stronger encapsulation of JDK internals
  • Dependency updates
  • Build tool updates
  • Framework compatibility
  • Reflection and proxy behavior changes
  • Container base image updates

This is especially relevant when moving from Java 8 to Java 17, 21, or 25.


Bytecode and Runtime Compatibility

Each Java version produces a corresponding class-file version. A newer JVM usually runs older class files, but an older JVM cannot run newer class files.

For example:

Java Version Class File Version
Java 8 52
Java 11 55
Java 17 61
Java 21 65
Java 25 69

So if code is compiled for Java 25, it generally requires a Java 25-compatible runtime.

To compile for a specific platform level, prefer:

javac --release 21 Example.java

The --release flag is safer than only using -source and -target because it also limits the available standard-library APIs to that Java version.


Practical Migration Path

If you are coming from Java 8, a practical learning and migration path is:

  1. Java 8 → 11
    • Learn modules conceptually, even if you do not modularize.
    • Replace removed Java EE dependencies explicitly.
    • Update build tools and libraries.
  2. Java 11 → 17
    • Adopt records where appropriate.
    • Use text blocks for multiline strings.
    • Use switch expressions.
    • Learn sealed classes and pattern matching.
  3. Java 17 → 21
    • Evaluate virtual threads.
    • Learn sequenced collections.
    • Use pattern matching for switch.
    • Review framework support.
  4. Java 21 → 25
    • Track finalized features from preview/incubator APIs.
    • Revisit concurrency patterns.
    • Update CI, containers, build plugins, and runtime images.

Mental Model

Think of the evolution like this:

Java 8  = functional Java arrives
Java 9  = modular Java begins
Java 11 = post-Java-8 LTS baseline
Java 17 = modern language Java
Java 21 = modern concurrency Java
Java 25 = next-generation LTS consolidation

Or more simply:

Java evolved from a verbose, class-heavy enterprise language into a more concise, expressive, cloud-ready platform while preserving strong backward compatibility.


What to Focus on First

If your goal is practical fluency, focus on these in order:

  1. Streams and lambdas
  2. var
  3. Modern collection factories
  4. Text blocks
  5. Switch expressions
  6. Records
  7. Pattern matching
  8. Sealed classes
  9. Virtual threads
  10. Modern build/runtime compatibility using --release

That path gives you the clearest understanding of how Java changed from Java 8 to Java 25.

Java Class File Format Versions

A compiled Java .class file starts with a fixed header (0xCAFEBABE), followed by a pair of numbers: minor_version and major_version. The pair (commonly written as major.minor, e.g., 52.0) identifies which Java platform level the bytecode targets. The JVM uses this to decide whether it can load the class. If the class was compiled for a newer platform than the JVM supports, you’ll get UnsupportedClassVersionError.

Why It Matters:

  • Backward compatibility: Newer JVMs can generally run older class files, but not the other way around.
  • Build reproducibility: Ensuring all modules target the same release avoids subtle runtime issues.
  • Tooling alignment: IDEs, build tools, containers, and CI images must agree on the target level to prevent version skew.

Quick mapping highlights:

  • Java 8 → 52.0
  • Java 11 → 55.0
  • Java 17 (LTS) → 61.0
  • Java 21 (LTS) → 65.0
  • Java 22 → 66.0, 23 → 67.0, 24 → 68.0, 25 → 69.0, 26 → 70.0, 27 → 71.0, 28 → 72.0
JDK Version Class File Format Version
1.0 45.0
1.1 45.3
1.2 46.0
1.3 47.0
1.4 48.0
5 49.0
6 50.0
7 51.0
8 52.0
9 53.0
10 54.0
11 55.0
12 56.0
13 57.0
14 58.0
15 59.0
16 60.0
17 61.0
18 62.0
19 63.0
20 64.0
21 65.0
22 66.0
23 67.0
24 68.0
25 69.0
26 70.0
27 71.0
28 72.0

Note:

  • Early JDK branding used 1.x (e.g., 1.5, 1.6) but these correspond to modern names 5, 6, etc. The table above reflects the modern naming for 5+.
  • There was no official 1.9 brand; Java 9 is simply 9 → 53.0 (already shown above).

How to check a class file’s version

  • Using javap (JDK tool):
    javap -v path/to/Some.class | find "major"
    

    Look for a line like major version: NN (e.g., 52 for Java 8). For modern compilers, minor is typically 0.

  • Reading the header directly (forensics style):

    1. Confirm magic bytes: CA FE BA BE.
    2. Next 2 bytes: minor_version.
    3. Next 2 bytes: major_version (e.g., 0x003D = 61 → Java 17).

How to compile for a specific Java level

  • Recommended (single flag):
    javac --release 21 -d out $(find src -name "*.java")
    

    --release consistently sets language features, APIs, and the class file version.

  • Legacy approach (not preferred, can mismatch APIs):

    javac -source 1.8 -target 1.8 -bootclasspath "%JAVA8_HOME%\\jre\\lib\\rt.jar" -extdirs ""
    
  • Maven (maven-compiler-plugin):
    <plugin>
      <groupId>org.apache.maven.plugins</groupId>
      <artifactId>maven-compiler-plugin</artifactId>
      <version>3.11.0</version>
      <configuration>
          <release>21</release>
      </configuration>
    </plugin>
    
  • Gradle (Groovy DSL):
    java {
      toolchain {
          languageVersion = JavaLanguageVersion.of(21)
      }
    }
    // Or explicitly set the target bytecode
    tasks.withType(JavaCompile).configureEach {
      options.release = 21
    }
    

Common failure and how to fix

  • Symptom:
    • java.lang.UnsupportedClassVersionError: … has been compiled by a more recent version of the Java Runtime.
  • Causes:
    • Running on an older JRE/JDK than the class file requires.
    • Mixed toolchains or inconsistent --release/target levels in a multi-module build.
  • Fixes:
    • Upgrade the runtime to meet the class file’s major.minor level; or
    • Recompile with an older target using --release <level> that matches your deployment runtime; and
    • Standardize toolchains via Maven/Gradle toolchains and CI images to avoid skew.

Tips and caveats

  • Prefer --release over -source/-target because it also validates against platform APIs for that release.
  • Preview features do not change the class file version; they require --enable-preview at compile and run time, but the mapping still follows the JDK’s version.
  • When publishing libraries, choose the lowest --release that matches your supported runtime matrix to maximize compatibility; consider multi-release JARs if you need newer APIs while keeping a baseline.

How do I handle database timeouts in JDBC?

In JDBC, “database timeouts” can mean a few different things, and you handle each at a different layer. The most practical approach is to set timeouts deliberately and then catch the right exception types so you can decide whether to retry, fail fast, or surface a user-friendly error.

1) Connection timeout (can’t connect / handshake takes too long)

a) DriverManager login timeout (global)

This limits how long DriverManager will wait when establishing a connection.

package org.kodejava.jdbc;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;

public class ConnectTimeoutExample {
    public static void main(String[] args) throws SQLException {
        DriverManager.setLoginTimeout(10); // seconds

        try (Connection c = DriverManager.getConnection(
                "jdbc:mysql://localhost/kodejava",
                "kodejava",
                "s3cr*t"
        )) {
            // connected
        }
    }
}

b) Driver-specific connect/socket timeouts (recommended)

Most drivers expose properties like connectTimeout and socketTimeout (names vary by vendor). These are often more reliable than setLoginTimeout.

Example pattern using connection properties:

package org.kodejava.jdbc;

import java.sql.Connection;
import java.sql.DriverManager;
import java.sql.SQLException;
import java.util.Properties;

public class DriverPropertiesTimeoutExample {
    public static void main(String[] args) throws SQLException {
        Properties props = new Properties();
        props.setProperty("user", "kodejava");
        props.setProperty("password", "s3cr*t");

        // Vendor-specific keys; check your driver docs:
        props.setProperty("connectTimeout", "10000"); // ms (example)
        props.setProperty("socketTimeout", "30000");  // ms (example)

        try (Connection c = DriverManager.getConnection(
                "jdbc:mysql://localhost/kodejava",
                props
        )) {
            // ...
        }
    }
}

Rule of thumb: set both a connect timeout and a read/socket timeout, otherwise a query can hang at the network layer even if you set a query timeout.


2) Query execution timeout (a statement runs too long)

Use Statement.setQueryTimeout(int seconds) (works for Statement, PreparedStatement, CallableStatement). On timeout, drivers typically throw a SQLTimeoutException (a subclass of SQLException).

package org.kodejava.jdbc;

import java.sql.*;

public class QueryTimeoutExample {
    public static void main(String[] args) throws SQLException {
        try (Connection c = DriverManager.getConnection("jdbc:mysql://localhost/kodejava", "kodejava", "s3cr*t");
             PreparedStatement ps = c.prepareStatement("SELECT * FROM product WHERE price > ?")) {

            ps.setBigDecimal(1, new java.math.BigDecimal("100.00"));
            ps.setQueryTimeout(5); // seconds

            try (ResultSet rs = ps.executeQuery()) {
                while (rs.next()) {
                    // consume results
                }
            }
        } catch (SQLTimeoutException e) {
            // This is your “query took too long” bucket.
            throw new RuntimeException("Query timed out; consider optimizing SQL or raising timeout.", e);
        }
    }
}

Important notes:

  • setQueryTimeout is enforced by the driver, and behavior can differ:
    • Some drivers send a cancel to the server.
    • Some only time out client-side.
  • If the thread is interrupted, or you want a manual escape hatch, you can also call Statement.cancel() from another thread.

3) Lock wait / deadlock timeouts (transaction waits too long)

These are not “JDBC timeouts” per se—they’re database concurrency timeouts. They usually surface as SQLException with:

  • SQLState like 40001 (serialization failure / deadlock, DB-dependent), or
  • vendor-specific error codes/messages (e.g., lock wait timeout exceeded).

Handling strategy:

  • Rollback the transaction.
  • Retry only if you can safely retry (best is retrying the whole transaction), and keep attempts small with backoff.

4) Pool acquisition timeout (you can’t get a Connection from the pool)

If you use a pool (HikariCP, DBCP, c3p0, etc.), also set a connection acquisition/checkout timeout. Otherwise, under load you’ll see “timeouts” that are actually “all connections are busy.”

This is configured on the pool, not via JDBC calls.


5) Catching and classifying timeouts correctly

Catch the specific subtype when possible

JDBC provides SQLTimeoutException:

try {
    // execute query/update
} catch (SQLTimeoutException e) {
    // query timeout bucket
} catch (SQLException e) {
    // everything else
}

Use SQLState for broad categories

If you need portability, SQLState prefixes help:

  • 08xxx → connection exception family (network/connection problems)
  • 40xxx → transaction rollback / concurrency issues (often retryable depending on DB)
static boolean isConnectionProblem(SQLException e) {
    String state = e.getSQLState();
    return state != null && state.startsWith("08");
}

6) Retry policy (only for the right failures)

Retries are useful for transient failures (deadlocks, lock timeouts, brief network blips), but dangerous for non-idempotent operations.

A safe baseline:

  • Retry 2–3 times max
  • Use jittered backoff
  • Retry only when:
    • you can retry the entire transaction, or
    • the operation is idempotent

Sketch:

package org.kodejava.jdbc;

import java.sql.SQLException;
import java.sql.SQLTimeoutException;
import java.time.Duration;
import java.util.concurrent.ThreadLocalRandom;

public class RetrySupport {
    public static <T> T withRetry(SqlSupplier<T> work) throws SQLException {
        int maxAttempts = 3;
        SQLException last = null;

        for (int attempt = 1; attempt <= maxAttempts; attempt++) {
            try {
                return work.get();
            } catch (SQLTimeoutException e) {
                // Query timed out: retry is usually NOT helpful unless you expect transient load.
                throw e;
            } catch (SQLException e) {
                last = e;
                if (!isRetryable(e) || attempt == maxAttempts) throw e;

                sleep(backoff(attempt));
            }
        }
        throw last; // unreachable
    }

    private static boolean isRetryable(SQLException e) {
        String state = e.getSQLState();
        if (state != null && state.startsWith("08")) return true;  // connection hiccup
        if (state != null && state.startsWith("40")) return true;  // tx rollback class (DB-dependent)
        return false;
    }

    private static Duration backoff(int attempt) {
        long baseMs = 100L * (1L << (attempt - 1)); // 100, 200, 400...
        long jitter = ThreadLocalRandom.current().nextLong(0, 100);
        return Duration.ofMillis(baseMs + jitter);
    }

    private static void sleep(Duration d) {
        try {
            Thread.sleep(d.toMillis());
        } catch (InterruptedException ie) {
            Thread.currentThread().interrupt();
        }
    }

    @FunctionalInterface
    public interface SqlSupplier<T> {
        T get() throws SQLException;
    }
}

7) Practical checklist (what to set in real apps)

  1. Pool acquisition timeout (if using a pool)
  2. Connect timeout (driver property)
  3. Socket/read timeout (driver property)
  4. Query timeout (setQueryTimeout)
  5. For transactions:
    • keep transactions short
    • handle deadlocks/lock timeouts with rollback and bounded retry