Coder Legion - Recent posts tagged openjdk

Oracle Plans Post-Quantum TLS for Java 8 and 11 in Late 2027, and Wants Testers Now

Tue, 27 Oct 2026 23:35:19 +0000

Security teams are starting to ask a question platform teams don't like: what's our plan for post-quantum encryption? For shops still running Java 8 or 11, the answer has mostly been a shrug.

At Oracle AI World in Las Vegas this week, I got a firmer one. I sat down with Georges Saab, senior vice president of Oracle's Java Platform Group; Donald Smith, vice president of product management for Java Platform; and Bernard Traversat, vice president of software development for the Java Platform Group. I asked about the schedule for hybrid post-quantum key exchange in TLS 1.3.

The feature is generally available in JDK 27. It arrived in JDK 25 with the October critical patch update. I laid out what comes next as I understood it: Java 21 and 17 in the first half of 2027, Java 11 and 8 in the second half. The team confirmed that was right.

Those are half-year windows, not release dates. And there is a condition attached.

Customers have been asking Oracle for post-quantum support as fast as possible. Now that it ships, the team wants them to use it. Many reply that they'd rather have it backported first. Oracle's answer is to test what already exists.

Smith said the key to stability is "just getting people using what we have, even though it's only in the latest."

There is a chicken-and-egg problem. The specification was only finalized in February, so many of the endpoints a Java client talks to don't support the hybrid exchange yet. Smith called the backport itself the hard part. For the next two to three months, the team is focused on stability so the backport starts from solid ground.

Feedback comes from two places. One is customers. The other is a group in OpenJDK that works with major third-party library projects, including Apache and Eclipse, and with the OpenSSL community.

Performance is the other worry. Java 8 shipped years before TLS 1.3 was final, and the team had to backport it. That taught them the backport has to be stable and fast on old hardware. A team tracks performance benchmarks on every release, including the new algorithms, he said. He gave no numbers.

If you run Java 8 or 11, waiting for the backport and then starting your testing is the slow path. Point a JDK 25 or 27 client at your post-quantum-capable endpoints, such as a gateway or proxy, and report what breaks. Oracle says it needs that feedback.

Backports aren't the only way out. Saab said he now regularly meets teams where most workloads are on Java 21.

He described the upgrade ladder this way. Going from 8 to 11 is the hardest step. Each step after that gets easier. "21 to 25 super easy," he said. The platform has been changed so that code survives upgrades better than it used to.

When teams do get stuck, the cause is usually outside the JDK. One is third-party libraries that nobody maintains. The other is the oldest problem: "when people used APIs that were not part of the public API," Saab said.

For finding those problems, Traversat pointed to Oracle's Java Management Service. It analyzes the APIs an application uses and reports deprecated APIs, changed behavior, and JVM argument changes between versions, such as 11 to 17 or 25. After that, he said, you still run the testing you use to certify the application.

I also asked how a team should verify code that an AI agent has refactored. Smith was direct: "I don't have a swift answer for that one." Saab said migration tooling is being built by other people. His team has helped groups inside Oracle migrate, to learn what the JDK could do better. Would the JDK team build migration tools itself? "I'm not saying we will never do that," he said.

So if you plan to use agents on a legacy Java codebase, the tools will come from outside the JDK. Verification still falls to your test suite.

The other date on your calendar is the patch schedule. Oracle announced in the spring that it is moving to monthly security updates across the company, not just for Java. Smith said the Java team will phase this in. "Next year we'll probably do 10 security updates and then it'll be every month thereafter," he said.

AI is part of the reason. "It's clear that AI has increased the rate at which you find vulnerabilities," Smith said. He added that it has also improved the team's ability to fix them.

He worried at first that system administrators would push back. They haven't. "The feedback is like nobody is surprised by this," he said. Some organizations will still have to adapt. A team on a quarterly change window is the obvious example.

Two items have no dates: non-hybrid key exchange and Merkle certificates. Smith said the work follows the IETF specifications and he wasn't sure enterprises could plan around it. His advice was to follow OpenJDK development. The issue trackers are open, and code already exists.

That caution is deliberate. "Never get ahead of the spec," Smith said. He pointed to the original java.util.Date as the example. An early implementation gained traction, it wasn't the best design, and the proper replacement took 10 to 15 years to arrive. Traversat added that anything shipped in the platform has to be supported for years, so Oracle moves conservatively.

For Java teams, the planning date is the second half of 2027 for Java 8 and 11. The work that decides whether that date holds starts now, and Oracle is asking for your help.

Java 26 Is Here: What Developers Actually Need to Know

Tue, 17 Mar 2026 14:00:00 +0000

Oracle released Java 26 on March 17, 2026. If you've been tracking the six-month release cadence, you know the drill — steady progress across language features, performance, and libraries. But this release has a few things worth stopping to read about, particularly if you're working on AI-integrated applications or just want Java to get out of your way more often.

Here's what matters for working developers.

The 10 JEPs at a Glance

Java 26 ships with 10 JDK Enhancement Proposals. None of them are finalized "standard" features this cycle — the ones closest to ready are still in preview or incubator — but several have reached a stage where it makes sense to experiment with them and give feedback.

JEP 530 – Primitive Types in Patterns, instanceof, and switch (Fourth Preview)

This one has been building for several releases. It removes restrictions on using primitive types in pattern matching, instanceof, and switch, making the language more consistent. If you've ever written extra conversion logic just to get primitives to work with switch patterns, this is the fix you've been waiting for. It also tightens dominance checks in switch constructs, so the compiler will catch more errors at compile time instead of at runtime.

JEP 525 – Structured Concurrency (Sixth Preview)

Structured Concurrency treats groups of related tasks in different threads as a single logical unit of work. That means cleaner cancellation, better error propagation, and no more thread leaks when something goes wrong mid-workflow. If you're building anything that fans out to multiple services or coordinates parallel tasks — including agentic AI patterns — this is worth learning now. It's been in preview long enough that the API is stable enough to build against.

JEP 529 – Vector API (Eleventh Incubator)

Yes, the Vector API is still in incubator. But it's also the mechanism that enables Java to execute SIMD vector computations on supported CPU architectures. If you're running AI inference, numerical computing, or data analytics workloads in Java, the performance difference over scalar operations is real. It's been available in incubator for long enough that projects like LangChain4j are already building on top of it.

JEP 526 – Lazy Constants (Second Preview)

Lazy constants let you defer initialization of objects that hold immutable data until they're actually needed — and the JVM still treats them as true constants for optimization purposes. This is particularly useful for AI and cloud-native applications where you want fast startup without loading everything upfront.

JEP 516 – Ahead-of-Time Object Caching with Any GC

This is the Project Leyden contribution in this release. It lets the JVM cache pre-initialized Java objects so they can be loaded quickly at startup — and it now works with any garbage collector, including ZGC. The result is faster startup and faster warm-up, which matters for serverless functions, containerized microservices, and any application where cold-start time affects performance.

JEP 517 – HTTP/3 for the HTTP Client API

HTTP/3 is now available in the Java HTTP Client with minimal code changes required. If your application talks to HTTP/3-capable servers, this update reduces latency and improves connection reliability automatically.

JEP 522 – G1 GC Throughput Improvement

Reduces synchronization between application threads and the garbage collector, increasing throughput under the G1 GC. This is an under-the-hood improvement — you don't have to change any code — but you should see it in benchmark results.

JEP 524 – PEM Encodings of Cryptographic Objects (Second Preview)

A new encoding API that handles cryptographic keys, certificates, and certificate revocation lists in the widely used PEM format. If you work with TLS, auth tokens, or any certificate-heavy workflow, this API significantly reduces the boilerplate involved.

JEP 500 – Prepare to Make final Mean Final

This one is a warning shot. Java is beginning to enforce "integrity by default" — which means using deep reflection to mutate final fields will now generate warnings. If you have libraries or frameworks that rely on this pattern, now is a good time to check. The JEP provides a migration path.

JEP 504 – Remove the Applet API

Applets are gone. The API was deprecated for removal in JDK 17, and it's now officially out. If somehow you still have Applet API calls in your codebase, it's time to address them.

Helidon AI: Building Agents as Microservices

One of the bigger announcements alongside Java 26 is the inclusion of Helidon in the new Oracle Java Verified Portfolio. For Java developers, Helidon AI is the most interesting part of that story.

Helidon AI extends the Helidon microservices framework to support building high-performance AI applications directly in Java. That includes out-of-the-box LangChain4j integration for connecting to AI models and embedding stores, a scalable virtual threads-based MCP server, and tooling to build AI agents structured as microservices.

If you've been building AI features in Python and wondering how to bring them closer to your Java services, Helidon is Oracle's answer. It's lightweight, built on Virtual Threads from the ground up, and aligns its release cadence directly with the JDK going forward.

Project Detroit: Java Gets JavaScript and Python Scripting

Oracle announced Project Detroit, which it plans to propose as an OpenJDK project. The goal is to let Java call JavaScript and Python directly, initially using the V8 and CPython runtimes.

The practical use case is clear: most AI libraries are Python-first. Rather than waiting for Java equivalents of every tool in the Python AI ecosystem, Project Detroit would let you call those libraries directly from Java code while keeping execution isolated. Oracle plans to eventually ship this as two components in the Java Verified Portfolio: Oracle JDK ScriptEngine for JavaScript and Oracle JDK ScriptEngine for Python.

This isn't available yet — it was announced as a forthcoming OpenJDK proposal — but it's worth watching. It addresses one of the more legitimate criticisms of Java for AI work today.

What the Java Team Is Most Excited About

During a pre-release briefing, Georges Saab, SVP of the Oracle Java Platform, was asked directly: what's the JEP developers are going to be looking for most in their workflows over the next 12 months?

"Right now, the stuff around Leyden is super exciting," he said. "We're going to see a lot of people looking at that, and the reason is because they can apply it to their code as-is. They don't have to do a bunch of changing. I think that longer term, you're going to see some of the things starting to come in around AI that are going to be super exciting. And we've got stuff right around the corner with Valhalla."

That's a useful signal. If you want to start with something that delivers immediate results without refactoring, Leyden (JEP 516) is where to start. The AI-oriented features — particularly the Vector API, Structured Concurrency, and the upcoming work in Valhalla — are the longer runway.

Post-Quantum Cryptography: Where Things Stand

Java 26 adds Hybrid Public Key Encryption (HPKE), building on the post-quantum cryptography work that started in JDK 24 with quantum-resistant ML-KEM and ML-DSA algorithm support. JAR signing now supports ML-DSA for post-quantum supply chain security.

Post-Quantum Hybrid Key Exchange for TLS 1.3 (JEP 527) is targeting JDK 27 in September 2026. Donald Smith, VP of Java Product Management, explained the deliberate timing during the briefing: "We're super confident on this now. We didn't want to do a release and then say, 'By the way, when you take up JDK 27, you're going to have to change things because the spec changed.' Based on our experience with TLS 1.3 a decade ago, we didn't want to screw this up."

The backport plan targets JDK 25 LTS first, then JDK 21 and JDK 17. If you're in a regulated environment or starting to evaluate PQC readiness, EA builds are already available at JDK.java.net and accepting feedback through June 2026.

VS Code Gets Notebook Support

The Java Platform Extension for VS Code now includes Java Notebook support, allowing you to run Java code interactively in a Jupyter-style notebook environment. The extension now has commercial backing through the Java Verified Portfolio, which means Oracle will support it for new JDK features immediately — including during Early Access builds.

For learning, prototyping, and teaching Java, this is a meaningful addition.

What to Actually Do With This

If you're on Java 21 LTS, there's no pressure to move to 26 in production. But it's worth running Java 26 in a dev environment to get familiar with the preview features, particularly Structured Concurrency and Primitive Types in Patterns. Both have been through enough iterations that they're close to final.

If you're building anything with AI integration, take a look at Helidon AI and LangChain4j with Virtual Threads — the combination is purpose-built for the kind of multi-model, multi-step workflows that agentic AI requires.

Java 26 is available now at dev.java. The full JEP list is at openjdk.org/projects/jdk/26.