The Java community has reason to be excited, as the highly anticipated JDK 25 has been officially released as a Long-Term Support (LTS) version. In other words, this makes it one of those releases that enterprises and developers alike will rely on for years to come. What really stands out in this release, though, is the strong focus on security.
In light of this, JDK 25 introduces TLS protocol-specific constraints via the jdk.tls.disabledAlgorithms property, giving administrators tighter control over handshake and certificate signature algorithms. Plus, TLS Keying Material Exporters are now supported in JSSE and SunJSSE, following RFC 5705 and RFC 8446.
It’s also worth noting that new SHAKE128-256 and SHAKE256-512 MessageDigest algorithms have been added, alongside HKDF support in SunPKCS11. On top of that, the XML Signature implementation has been updated to Santuario 3.0.5, with support for SHA-3-based ECDSA signatures.
Several useful changes landed in the core libraries. Developers can now use Reader.readAllAsString() and Reader.readAllLines() for simpler text handling, while stdin.encoding introduces a standard way to check or override the charset used by System.in.
In java.lang, a new getChars(int, int, char[], int) method has been added to CharSequence and CharBuffer, making bulk character reads more efficient. Networking APIs also see updates, with new ways to limit response body sizes in HttpClient and a connectionLabel method to better identify HTTP connections.
Plus, the ZIP file system provider now allows mounting archives in read-only mode, which helps in scenarios where integrity and immutability matter.
Regarding the debugging Improvements, JDK 25 updates the java.security.debug system property output:
- The older
+threadand+timestampoptions (introduced in JDK 23) no longer have any effect. - Now includes thread ID, thread name, caller location, and timestamps by default.
Moreover, the G1 garbage collector reduces memory overhead by grouping regions into shared card sets, which lowers pause times during mixed collections. In addition, compact object headers introduced in JDK 24 are now a supported product option, potentially reducing Java heap footprints.
Java Flight Recorder (JFR) gains a new @Contextual annotation, letting developers tie higher-level request information—such as trace IDs—to low-level events like lock contention. Thread dumps generated by HotSpotDiagnosticMXBean and jcmd also now include lock details and link to a JSON schema for better tool support.
As with every LTS release, some legacy features are retired. JDK 25 removes several outdated root certificates (Baltimore CyberTrust, Camerfirma), disallows deprecated Socket constructors for datagram sockets, and drops rarely used PerfData sampling.
Apart from that, several permission classes tied to the old Security Manager have been deprecated for removal, reflecting the broader move away from that model. The option UseCompressedClassPointers is also deprecated and will be removed in a future release, with compressed pointers now the default.
Lastly, but very important, with the release of JDK 25, Java has officially dropped support for the aging 32-bit x86 architecture. The move comes through JEP 503, which removes both the source code and build support for this long-standing port.
The decision follows last year’s deprecation in JDK 24 under JEP 501, making the removal expected but still significant for anyone relying on legacy 32-bit systems. While the Zero interpreter remains available as a fallback for running Java on less common 32-bit platforms, mainstream support now focuses entirely on 64-bit hardware.
Of course, JDK 25 LTS additionally includes hundreds of smaller enhancements and countless bug fixes. To review everything in detail, visit the release notes.
As I mentioned in the beginning, JDK 25 is the newest long-term support release, following JDK 21 from 2023, which is supported until 2029, and JDK 17 from 2021, supported until 2026. According to Oracle’s announcement, JDK 25 will be supported for at least eight years. Downloads are available here.
Most notably they dropped all support for the old x86 (32 bit) CPU architecture. That will add pressure to developers who have to maintain software for hardware with those CPUs, in particular in the embedded world. Oracle’s decision may also have an impact on those people in the world who simply cannot afford new hardware. Of course Oracle as a company couldn’t care less about poor people. But developers of embedded systems may think twice about using Java in the future. Who knows when Oracle will drop support for ARMv7, for instance.
Thanks for mentioning that, Jeff. Article updated.