Key Takeaways
- Start new production applications on Java 25 LTS, provided your framework, build tools, and deployment platform support it.
- As of October 17, 2026, Java 27 is the latest feature release; Java 25 is the latest LTS release. The official release list distinguishes their release dates.
- Choose a specific JDK distribution and update policy, not just a Java version number.
- For Java 8 or 11 applications, plan and test the migration. Changing a container image isn't a compatibility assessment.
Updated October 17, 2026. For most new production projects, use a maintained Java 25 LTS distribution. Choose Java 21 when a required component hasn't certified Java 25, and retain Java 17 only when a concrete compatibility requirement justifies it.
The useful question isn't simply “which Java version should I use?” It's which combination of release, distributor, support commitment, and application compatibility you can operate safely.
Versions vs Editions: What Are You Choosing?
A version identifies a platform release, such as Java 25. An edition describes the platform's scope; a distribution is the particular implementation and binary package you install.
Java SE: The Standard Platform
Java Standard Edition defines the core platform and APIs used by ordinary Java applications. The Java SE and JDK API documentation distinguishes standard modules from JDK-specific modules. If you're learning, start with a JDK and our Java beginner tutorial.
Java EE and Its Successor, Jakarta EE
Java EE is the historical enterprise-platform name. Its standards continued under the Eclipse Foundation as Jakarta EE, the successor to Java EE. You select compatible enterprise libraries or an application server alongside a JDK; Jakarta EE isn't an alternative JDK download or a replacement for Java SE.
Java ME: Constrained Devices
Java Micro Edition targets device-specific environments, including resource-constrained embedded systems. Don't treat it as the default platform for modern mobile application development.
Which Java Version Should You Use in 2026?
The dates below are general-availability dates from the official JDK release history. LTS labels identify releases selected for longer maintenance; the actual updates and support you receive depend on your distributor.
| Release, support label, and GA date | Practical selection guidance |
|---|---|
| Java 25 (LTS) — September 16, 2025 | Default starting point for a new production application. |
| Java 21 (LTS) — September 19, 2023 | Choose when your stack supports 21 but isn't ready for 25. |
| Java 17 (LTS) — September 14, 2021 | Keep for a documented compatibility constraint, with a migration plan. |
| Java 11 (LTS) — September 25, 2018 | Maintain existing systems only with a verified update source and lifecycle. |
| Java 8 (LTS) — March 18, 2014 | Treat as a legacy-platform decision, not a new-project default. |
| Java 27 (non-LTS) — September 15, 2026 | Choose deliberately when you can keep upgrading on the feature-release cadence. |
Java 25 vs Java 21
Prefer Java 25 unless something in your stack blocks it. Java 25 finalized scoped values, compact source files and instance main methods, and flexible constructor bodies; these are documented in the JDK 25 changes.
Java 21 already includes finalized virtual threads, record patterns, and pattern matching for switch. Those are Java 21 features, not Java 23 introductions. If you already run a maintained Java 21 build, schedule the move to 25 around compatibility testing rather than an arbitrary deadline.
Before choosing either release, check your exact framework and application-server versions, database drivers, monitoring agents, annotation processors, and build plugins. A framework's minimum Java version doesn't establish its maximum tested version.
Java 17: A Compatibility Choice
Use Java 17 when a required platform or dependency restricts you to it, not because “older means safer.” Our Java 17 feature overview provides background, but your distributor's lifecycle determines whether a particular installation remains maintained.
Java 11: Verify the Update Source
Java 11 is an older LTS release, not automatically an unsupported one. Both Oracle and Adoptium still list Java 11 maintenance options in their respective Oracle support and Temurin availability roadmaps. For an existing system, establish who supplies security updates before deciding how urgently to migrate.
Java 8: Plan Beyond Language Compatibility
Java 8 introduced lambda expressions and the java.time date/time API, documented in its release overview. Maintaining a Java 8 application requires more than preserving that source syntax: inventory its libraries, launch scripts, runtime dependencies, and supported deployment environments.
Java 27: Latest Doesn't Mean Longest-Supported
Use Java 27 when its capabilities justify a faster upgrade rhythm. Oracle's roadmap lists Java 27 as non-LTS, with Premier Support through March 2027. That's an Oracle support commitment, not a universal deadline for every Java 27 build.
What LTS and Support Actually Mean
Java feature releases arrive every six months. LTS designations and support terms are vendor policies; Oracle currently plans LTS releases every two years. Its support roadmap lists Java 17 Premier Support through September 2026 and Extended Support through at least September 2029 for eligible customers.
By contrast, Adoptium lists Temurin 17 binary availability through at least October 2027. Its community support policy is not a paid service-level agreement. Record the vendor, release, support tier, and end date together; “supported until 2030” without that context isn't actionable.
Oracle JDK vs OpenJDK: Choose a Distribution
OpenJDK is the open-source project and codebase behind many JDK distributions, not a single download with one support policy. Adoptium explains its relationship to OpenJDK in its project and licensing overview. Oracle publishes both Oracle JDK and separate Oracle OpenJDK builds, with different licensing and availability terms described in its licensing FAQ.
| Distribution | Licensing and availability | Updates and support |
|---|---|---|
| Oracle JDK 25 | Oracle No-Fee Terms and Conditions permit commercial and production use subject to the license. | Oracle currently plans NFTC updates through September 2028; commercial support is a separate entitlement. |
| Eclipse Temurin 25 | OpenJDK-based binaries; the OpenJDK code is licensed under GPLv2 with exceptions, including the Classpath Exception. | Adoptium publishes an availability roadmap and community support; contracted support comes from commercial providers. |
| Amazon Corretto 25 | No-cost OpenJDK distribution under GPLv2 with the Classpath Exception. | Amazon plans quarterly updates and urgent fixes outside that cycle; assistance through AWS Support is distinct from binary maintenance. |
Use the Oracle licensing FAQ, Temurin support policy, and Corretto FAQ to compare these commitments. Check available operating-system and CPU packages, container images, runtime-only packaging, patch delivery, and support escalation before standardizing.
My default would be Temurin 25 when community-maintained binaries meet the project's needs. Choose another distribution when its platform coverage, patch policy, or support contract is a better fit. Don't confuse a no-cost download with an incident-response commitment.
JDK vs JVM vs JRE: What Should You Install?
- JVM: The virtual machine that executes Java bytecode.
- JRE: The runtime environment: a JVM plus the libraries and supporting files needed to run applications.
- JDK: A development kit that can run applications and includes tools such as the javac compiler.
Install a JDK for development. For deployment, use a maintained JDK image or an appropriately assembled runtime image. Oracle stopped providing separate JRE and Server JRE downloads with JDK 11, as documented in the JDK 11 migration guide; packaging options differ between distributors.
Create a Small Runtime With jlink
jlink assembles selected modules and their dependencies into a custom runtime image. Run this example in an empty directory with JDK 25 tools on your PATH:
mkdir classes
cat > Hello.java <<'JAVA'
public class Hello {
public static void main(String[] args) {
System.out.println("Hello from a custom runtime");
}
}
JAVA
javac -d classes Hello.java
jlink --add-modules java.base --output runtime
./runtime/bin/java -cp classes HelloThis example needs only java.base and keeps the application classes outside the runtime image. Your real application's modules, libraries, service providers, and reflective loading determine what you must include. You're responsible for rebuilding and redeploying custom images when the underlying JDK receives fixes.
Verify the Java Your Build and Deployment Actually Use
Check both the runtime and compiler. The java launcher and javac compiler expose version commands; the launcher can also print system properties:
java -version
javac -version
java -XshowSettings:properties -versionInspect java.home and java.vendor, then repeat the runtime check in your deployment environment. Your shell's Java installation is not proof of the JDK selected by an IDE, build tool, service launcher, or container.
Read Modern Version Strings
Oracle documents the full version string 25.0.4.1+1 for Oracle JDK 25.0.4.1. This is a documented version component, not fabricated console output.
The modern numeric format is FEATURE.INTERIM.UPDATE.PATCH: here, 25 is the feature release, 0 the interim component, 4 the update, and 1 the patch. The suffix +1 identifies the build. See the version-string specification; inspect the vendor and VM lines in your actual output as well.
Declare a Build Toolchain
In an existing Gradle project, install your chosen JDK 25 and use a compatible wrapper. Gradle's compatibility matrix lists Java 25 toolchain support and support for running Gradle on Java 25 from Gradle 9.1.0 onward. A minimal build.gradle.kts is:
import org.gradle.api.tasks.compile.JavaCompile
import org.gradle.jvm.toolchain.JavaLanguageVersion
plugins {
java
}
java {
toolchain {
languageVersion = JavaLanguageVersion.of(25)
}
}
tasks.withType<JavaCompile>().configureEach {
options.release = 25
}The toolchain configuration selects the JDK for standard Java compilation and test tasks; options.release sets the language, bytecode, and Java SE API target. A language-version declaration doesn't pin an exact vendor or security-update build. For a library targeting Java 21, set the release target to 21 and test on that runtime too.
Migration Checklist for Java 8 and Java 11
Follow an assessment-and-test process, not a container-tag substitution. Oracle's migration preparation guide recommends trying the existing application on the target runtime before recompiling, then updating libraries and investigating compatibility issues.
- Inventory the complete stack. Include frameworks, application servers, build wrappers, compiler and test plugins, annotation processors, native libraries, and monitoring agents.
- Separate runtime and source upgrades. First test the existing artifact on the target JDK. Then rebuild with an explicit release target; don't introduce new language features during the initial compatibility investigation.
- Find internal API dependencies. Use jdeps with its --jdk-internals option. Static analysis doesn't detect every reflective dependency, so a clean report doesn't replace execution tests.
- Review removed components and access restrictions. JAXB and JAX-WS stopped being bundled with JDK 11. JDK 17 strongly encapsulated JDK internals, which can expose dependencies on unsupported reflective access. Consult the JDK 11 changes and cross-release migration guide.
- Test security integrations. Review TLS negotiation, accepted algorithms, certificate chains, truststores, and authentication against the security changes. Don't weaken production security settings merely to make an old integration pass.
- Test behavior and capacity. Exercise encoding, locale-sensitive formatting, serialization, startup, memory use, garbage collection, and latency under representative load. Review obsolete JVM flags rather than copying them forward.
- Stage the rollout. Update launch scripts and deployment images, compare production metrics, and keep a tested rollback artifact.
Docker packages your application and runtime; it doesn't repair incompatible code. Follow Docker's image maintenance guidance: record the base-image tag and digest for reproducibility, and deliberately refresh and rebuild to receive fixes.
Common Mistakes
- Picking an LTS label without a maintenance source. Document where updates come from and who owns applying them.
- Treating preview features as permanent APIs. Evaluate their status in the exact release you're adopting; the Java 23 history above shows why that distinction matters.
- Assuming a successful startup proves compatibility. Verify integrations, scheduled jobs, error paths, and production-like resource limits before rollout.
FAQ
What is the latest Java LTS version?
As of October 17, 2026, Java 25 is the latest LTS release, and Java 27 is the latest feature release. Java 25 reached general availability on September 16, 2025, according to the official release history.
Should I use Java 25 or Java 21 for a new application?
Start with Java 25 if your framework, libraries, build tools, and hosting platform support it. Choose Java 21 when a specific compatibility requirement blocks Java 25, and document when you'll reassess that constraint.
Is Java 17 still supported, and by which vendors?
Oracle offers subscription-based support for Java 17, and Adoptium continues publishing Temurin 17 updates under its own roadmap. Check the exact distributor, support tier, and lifecycle rather than relying on the LTS label; the Temurin policy distinguishes community support from contracted support.
What is the difference between an LTS release and a feature release?
Feature releases introduce platform changes on Java's six-month cadence; an LTS release is also a feature release selected by a vendor for longer maintenance. LTS doesn't freeze your security-update level or guarantee identical support across distributions, as the Oracle roadmap illustrates.
Do I need a JDK or a separate JRE to run a Java application?
A JDK can both develop and run Java applications, so you don't need a separate JRE alongside it. For deployment, use a maintained JDK image or an application-appropriate custom runtime; Oracle stopped offering separate JRE downloads with JDK 11, as its migration guide explains.
Further Reading
- Official JDK release history — release dates and planned updates.
- Oracle Java SE Support Roadmap — LTS designations, support tiers, and licensing transitions.
- Oracle Java SE Licensing FAQ — terms for specific Oracle binaries.
- Eclipse Temurin support policy — binary availability and community-support scope.
- Amazon Corretto FAQ — licensing, maintenance, and lifecycle commitments.
- Preparing for JDK Migration — testing, dependency updates, and analysis.
- Gradle Java toolchains — selecting build JDKs and release targets.
- jlink command reference — assembling and maintaining custom runtimes.
