Final means final - JDK 26

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Final means final - JDK 26

hharrison
Administrator
https://openjdk.org/jeps/500

Honestly haven't looked at the implementation yet, but was curious if this will have any impact on the current situation generating new warnings?
Reply | Threaded
Open this post in threaded view
|

Re: Final means final - JDK 26

Sven Gothel
Administrator
Thanks for the heads up Harvey.

Out of my head, I am not aware that we try to mutate immutables, systematically.
For the next release I shall add a test run w/ the OpenJDK 26  of course, good call.

JogAmp uses 'static final' fields with same objectives, i.e. allowing the compiler
to modify and optimize code (similar to virtual interface functions),
removing lookups and branches.
Reply | Threaded
Open this post in threaded view
|

Re: Final means final - JDK 26

hharrison
Administrator
In the jaamsim context, Java 25 was actually a very significant upgrade. so much so that we're likely to begin shipping a multi-release jar so we can take advantage of virtual threads and scoped values which is much much faster and way more scalable than the previous approach we were using to capture thread contexts in the event execution code.

Harvey
Reply | Threaded
Open this post in threaded view
|

Re: Final means final - JDK 26

Sven Gothel
Administrator
Great, yes you mentioned these details.
Can you show a few git commits to review your application of mentioned features? Thank you.

Edit: A little overview of the tech mentioned by Harvey <https://www.baeldung.com/java-20-scoped-values>
Reply | Threaded
Open this post in threaded view
|

Re: Final means final - JDK 26

hharrison
Administrator
There are three commits on the java25 branch that have the full story.

https://github.com/jaamsim/jaamsim/tree/java25

All of the thread management and scopes are controlled from the EventManager class. This one class is the only one that requires the multiple versions as we've been refactoring over time to simplify how many multiversion classes we'd have to deliver.

Jaamsim has a custom threadpool and subclasses of Thread (Process) that allows direct control of thread execution (only one at a time) with the ability to look up the current eventmanager from whatever Process is running. This all gets replaced with scopedvalues to look up the eventmanager and virtual threads are created instead of taken from a pool.

Context switching between runnable threads is quite a bit faster using virtual threads, as essentially the single native thread is just trading in the context from the virtual thread instead of actually switching to another OS-level thread. Happy to discuss in case anyone is interested.