Oracle has shipped Java 26, a short-term release, and introduced Project Detroit, which promises faster interop between Java, JavaScript, and Python. The shift represents a significant departure from Oracle's earlier strategy: instead of attempting to rebuild JavaScript and Python from scratch on the JVM, the company is now embedding the actual V8 and CPython runtimes directly into the Java process.
This pragmatic change addresses a fundamental problem that has haunted Java's polyglot ambitions for years. The JavaScript ecosystem is built almost entirely on V8 or Node.js running on V8. Similarly, Python developers expect CPython's behaviour. Previous attempts, including Project Nashorn, failed because reimplementing these languages meant constantly fighting compatibility battles with the actual implementations that dominate in production.
Bernard Traversat, VP software development at Oracle, explained the rationale to The Register:
"The novel approach that we are taking with Detroit is that we are embedding the V8 and CPython runtime directly inside the JVM process."By using the actual runtimes, JavaScript and Python's corner cases become manageable, and security isolation improves between the Java heap and the V8 or CPython heap.
Java 26 will be supported for just six months, until the release of Java 27 later this year. However, Project Detroit carries longer significance. It will be proposed as an OpenJDK project soon and will be presented at the JavaOne event in Redwood City, California. The initial languages will be JavaScript and Python, with other languages to follow. This move suggests Oracle views cross-language interoperability as a fundamental feature rather than a side project.
The release also marks a strategic consolidation of Oracle's Java ecosystem tools. Project Helidon, an open source framework for microservices, will be contributed to the OpenJDK and have its versions aligned with those of the JDK, enabling immediate use of new JDK features and alignment of LTS releases. The company is also introducing the Java Verified Portfolio (JVP), described as a set of services, libraries, frameworks, modules, and tooling that are supported and validated for enterprise use. The JVP consists of Project Helidon, JavaFX, and the Java platform extension for Visual Studio Code.
Commercial support for JavaFX, a rich media and graphical framework, has been reintroduced because of interest in interactive visualizations in AI and analytics applications. This reflects a pragmatic business decision: rather than view Java components in isolation, Oracle is bundling them with enterprise support guarantees, reducing the friction for organisations evaluating multiple Java frameworks.
Java 26 itself delivers incremental improvements rather than transformative features. Ten features are officially targeted to JDK 26: a fourth preview of primitive types in patterns, instanceof, and switch, ahead-of-time object caching, an eleventh incubation of the Vector API, second previews of lazy constants and PEM encodings of cryptographic objects, a sixth preview of structured concurrency, warnings about uses of deep reflection to mutate final fields, improving throughput by reducing synchronization in the G1 garbage collector, HTTP/3 for the Client API, and removal of the Java Applet API.
The removal of the Applet API marks a full circle for Java. The Java applet API has been removed because neither recent JDK releases nor current web browsers support applets. One of the original rationales for JavaScript, created by Netscape in 1995, was to script Java applets. Java applets are long gone, but Project Detroit shows that the need for interop between these two languages remains.
For enterprises, the consolidated strategy offers both clarity and risk reduction. By aligning Helidon releases with Java versions and offering unified support through the JVP, Oracle is making the case that Java's foundation is solid enough to build on. The real test will come when Project Detroit moves from prototype to production use. If the embedded-runtime approach succeeds at last, it could reshape how the JVM interoperates with the broader software ecosystem.