For openjdk 24 Currently (as of November 20, 2024) there are already 24! (In words: twenty-four) JEP was planned. This does not fit into the next release number. This is also a new record since development switched to a semi-annual release cycle in 2018. And this number may increase further. Rampdown phase one with freeze facility for the next edition will start from December 5 only. And because there are so many JEPs (JDK Enhancement Proposals) this time, we will take a first look at the most interesting points from the developer’s perspective that are currently planned. More details can be found in the respective JEP.
Advertisement
As a software architect, consultant and trainer at Embark Software Consulting GmbH, Falk Sippach is always looking for a spark of passion that he can ignite in his participants, customers and colleagues. He has been supporting agile software development projects mostly in Java environment for more than 15 years. As an active part of the community (co-organizer of JUG Darmstadt), he likes to share his knowledge in articles, blog posts as well as in lectures at conferences or user group meetings and is involved in the organization of various expert events. stands by. Falk tweets at @sippsack.
We’ll look at the remaining features in a later post. Perhaps some more will be added. So we can be excited to see what happens in the next two weeks.
JEP 485 – Stream Gatherers
After two previews it is now being finalized. The Streams API introduced in Java 8 now supports adding your own intermediate operations. This means that the data in the stream can now be transformed in a better, more optimized way than some of the built-in intermediate operations previously could. This means that stream pipelines can now be implemented more flexibly and unambiguously. OpenJDK also provides some new operations: fold
, mapConcurrent
, scan
, windowFixed
And windowSliding
More could be followed relatively easily in the future.

JEP484 – Class File API
After two previews, the new standard for parsing, generating, and transforming Java bytecode (class files) based on the Java Virtual Machine specification is now being finalized. In the future, all JDK components can be migrated to this standard API. Ultimately, JDK developers can remove internal copying and thus the dependency on the third-party library ASM.
JEP 488 – Primitive Types in Patterns, Examples, and Switch (2nd preview)
This second preview is about expanding pattern matching so that primitive data types are preferred. int
, byte
And double
Can be used in all pattern contexts, i.e. when instanceof
and in switch
This means that developers have fewer limitations and special cases and can also use primitive and reference data types interchangeably in the context of type patterns or as components in record patterns. There have been no changes since the first preview, but the JDK developers want to collect further feedback.
JEP 499 – Structured Concurrency (4th Preview)
When processing multiple parallel subtasks, structured concurrency allows implementation in a particularly readable and maintainable manner. Alternatively, developers have previously been able to use parallel streams, executor services, or reactive programming for this purpose. All are very powerful approaches, but they make simple implementations unnecessarily complex and error-prone. Structured concurrency treats groups of related tasks as a single unit of work, simplifying error handling and cancellation of tasks and increasing reliability and observability. There are no changes from the previous preview. The creators of OpenJDK would like more feedback from the “real” world.
JEP 487 – Scoped Values ​​(4th Preview)
Scope was introduced so that immutable data could be shared and used across both intra-threaded calls and child threads. Scoped values ​​are easier to understand, but their goals are the same ThreadLocal
-Variable. They have less space and time requirements, especially when used with virtual threads (JEP 444) and structured concurrent (JEP 480) used. This time there is a change: ways callWhere()
And runWhere()
were out of class ScopedValue
Removed. However, its functionality can still be called through an object of the Carrier class, which has the method where()
From ScopedValue
Was sent back. This makes the API completely fluent. Celebration call()
By the way, during the process gives a result run()
Returns nothing.
JEP 489 – Vector API (Ninth Incubator)
Vector API is a dinosaur among JEPs and is now in its ninth year as an incubator. It appears in regular releases since Java 16. It is about supporting the modern possibilities of SIMD computer architecture with vector processors. Single Instruction Multiple Data (SIMD) allows multiple processors to process different data at the same time. Parallelization at the hardware level reduces the effort required for computationally intensive loops using the SIMD principle. The reason for the long incubation phase is related to coordination with Project Valhalla. We are waiting for improvements to the type system (JEP 401: Value Classes and CommoditiesBefore finalizing the Vector API, the JDK developers want to convert the current value-based classes (reference types) to value classes (without object identity). This may take some time, as value types are not yet planned for OpenJDK 24. But at least Brian Goetz (Java Language Architect at Oracle) announced in the summer of 2024 that he had made a breakthrough in the implementation of the Valhalla project after 10 years. The first preview may possibly appear here with OpenJDK 25.
JEP 486 – Permanently Disable Security Manager
Security Manager was often used to secure client-side Java code (rich clients, applets), but rarely for server side. Apart from this, its maintenance is also expensive. With Java 17 (2021) it was marked as deprecated for removal. Now its internal expansion is being done. It can no longer be activated and other Java platform classes no longer reference it. However, this change is not likely to impact most applications, libraries, and devices. In one of the future Java versions, the Security Manager API will be permanently removed.
JEP 492 – Flexible Constructor Bodies (3rd Preview)
In constructors, statements can now be placed before the explicit constructor call (super()
Or this()
) to sound like. Although these statements cannot refer to the instance being created, they can validate or change parameters or access fields of the superclass. Initializing fields before calling another constructor makes the class more reliable when, for example, methods are overridden.
JEP 494 – Module Import Declarations (2nd preview)
This means that all exported packages of a module can now be imported into Java at once. This makes it easier to reuse modular libraries. By the way, it is not necessary that the importing code itself be contained in a module. There are two expansions in this second preview. On the one hand, the restriction on transitive dependencies from java.se modules (a kind of aggregator modules without their own packages/classes) to java.base has been removed. This means you can now import the entire Java SE API by importing this one module. Furthermore, it is now possible to import so-called types of on demand declarations (for example) import java.util.*
) Cover previous module import declarations. For example, if java.base and java.sql modules are imported, there will be ambiguity in using the class. Date
They are available as java.util.Date
and as java.sql.Date
Through on-demand announcement import java.util.*
will be in that situation java.util.Date
used.
JEP 495 – Simple Source Files and Instance Main Methods (4th Preview)
The goal is to make it easy for beginners to get started with Java and to give experienced developers the opportunity to easily create and run small applications. Beginners and advanced users alike don’t have to deal with language functions designed for larger programs. This fourth preview will collect further feedback. Simple Java source files that contain only a simplified language, while maintaining the existing Java toolchain and not with the intention of introducing a separate dialect for Java main
-Create simple, script-like programs consisting of methods (without class declaration). Additionally, new static methods make it easier to use standard inputs and outputs. print()
, println()
And readln()
Class java.io.IO
Some of these are imported automatically, meaning the functions are ready to use.
(rme)
