JDK 24 Feature Freeze / Permanently Disabling the Security Manager
by David Delabassee
Welcome to the final OpenJDK Quality Outreach update of 2024!
JDK 24, scheduled for General Availability on March 18, 2025 [1], is now in Rampdown Phase One (RDP1) [2]. At this point, the overall JDK 24 feature set is frozen and only low-risk enhancements might still be considered. You will find below the final list of the 24 JEPs that were integrated into JDK 24 as well as JDK 24 technical materials in the last section.
This QO update also covers 3 important heads-ups related to security, integrity and JDK 24.
The next key milestone is early February with the first JDK 24 Release Candidate builds. That means that we have a few weeks, modulo the end of year break, to find and hopefully address any issue that your projects might encounter. So, please let us know if you encounter any issue with the JDK early-access builds.
[1] https://openjdk.org/projects/jdk/24/
[2] https://mail.openjdk.org/pipermail/jdk-dev/2024-December/009672.html
# Heads-up - JDK 24: Permanently Disabling the Security Manager
Introduced to enforce the principle of the least privilege, the Security Manager was designed to prevent unauthorized code from accessing sensitive resources (ex. files, network connections, etc.). While effective in theory, it has fallen short in practice for multiple reasons: complexity, limited adoption, maintenance overhead and evolving threat landscape.
In Java 17, the Security Manager was deprecated for removal under JEP 411 [3]. In JDK 24, its functionality will be effectively disabled via JEP 486 [4]. Key changes include:
- Disabling the Security Manager - it will no longer be possible to enable the SM at startup using command-line options, nor will it be possible to install a custom SM during runtime.
- Rendering the Security Manager API non-functional - the SM API will remain present for compatibility but will no longer have any operational effect.
- Improving maintainability - thousands of lines of code dedicated to supporting the Security Manager will be removed, freeing OpenJDK contributors to implement modern security features.
Developers and enterprises using older Java versions or legacy applications relying on the Security Manager will retain access until JDK 24. Beyond that, they are encouraged to transition to alternative sandboxing and API interception mechanisms.
## Call to Action
The deprecation of the Security Manager in JDK 17 had little to no impact on most Java developers. Warnings issued in JDK 17–23 generated minimal discussion in the Java ecosystem, highlighting its limited relevance. Furthermore, major frameworks and tools (ex. Jakarta EE, Ant, Tomcat, etc.) have already removed support for the Security Manager, reinforcing the trend.
For applications still dependent on the Security Manager, the JDK offers options to identify and address its usage:
- jdeprscan [5] scans a JAR file for the usage of deprecated API elements, and it helps find code using these methods.
- Messages on the console warnings highlight Security Manager usage during runtime.
- Check how you launch your Java application - with the Security Manager allowed or enabled via command line options, or policy files that require it to be installed and configured.
These tools give code maintainers the necessary insights to transition away from the Security Manager before its complete removal in future JDK releases. By taking these steps, you will ensure a smooth transition from the Security Manager while adopting more effective security practices.
This is a summary; for more details, make sure to read JEP 486 [4].
[3] https://openjdk.org/jeps/411
[4] https://openjdk.org/jeps/486
[5] https://dev.java/learn/jvm/tools/core/jdeprscan/
# Heads-up - JDK 24: Prepares Restricted Native Access
Any interaction between Java code and native code, be it via the Java Native Interface (JNI) API or the Foreign Function & Memory (FFM) API, is risky in the sense that it can compromise the integrity of applications and of the Java Platform itself, for example by causing JVM crashes, even after the native code completed execution. According to the policy of integrity by default, all JDK features that are capable of breaking integrity must obtain explicit approval from the application’s developer. JDK 24, by means of JEP 472 [6], prepares that by aligning the behaviors of JNI and FFM by:
- Printing warnings for all restricted operations (with the goal to turn these into exceptions in a future release).
- Expanding the command-line options `--enable-native-access` and `--illegal-native-access` to govern restricted operations of both APIs.
Note that this is a change for JNI, which used to not trigger such warnings, as well as for FFM, which used to forbid restricted operations by default. Starting with JDK 24, both APIs behave uniformly by printing warnings. In the future, both APIs will throw exceptions instead. The intent is neither to discourage the use of, deprecate, or even remove JNI nor to restrict the behavior of native code called via JNI or FFM. The goal is to ensure that applications and the Java Platform have integrity by default while giving application operators the tools they need to selectively opt-out where needed.
This is a summary; for more details, please read the full Heads-Up [7] and JEP 472 [6].
[6] https://openjdk.org/jeps/472
[7] https://inside.java/2024/12/09/quality-heads-up/
# Heads-up - JDK 24: Security Properties Files Inclusion
Managing security properties across multiple JDK releases can be a challenge, particularly in environments requiring centralized control and distinct security profiles. To address this and starting with JDK 24, the Java Platform now allows the main security properties file (`${java.home}/conf/security/java.security`) or any file specified via the `java.security.properties` system property to include additional files. This inclusion is recursive, allowing for nested configurations, provided no cycles occur.
The `include` keyword is reserved and cannot be used to define security properties, as any attempt to do so results in an unchecked `IllegalArgumentException`. The inclusion mechanism enhances security by explicitly listing files in the main configuration file, preventing misconfigurations by throwing a fatal error if a file is missing or inaccessible. It also forbids including directories or URLs, ensuring strict control over which files are included. Users must ensure proper permissions for included files to avoid tampering, such as enforcing secure file permissions. The system supports a clear priority for security property overrides based on the order of inclusion, and updates to a single file automatically propagate across all configurations.
This enhancement offers better control and adaptability over Java security properties for developers, system administrators and infrastructure engineers.
This is a summary; for more details, please read the full Heads-Up [8] and the JDK 24 release notes [9].
[8] https://inside.java/2024/12/10/quality-heads-up/
[9] https://jdk.java.net/24/release-notes#JDK-8319332
# JDK 24 Early-Access Builds
The JDK 24 early-access builds 28 are available [10] and are provided under the GNU General Public License v2, with the Classpath Exception. The Release Notes are available here [11].
## JEPs integrated into JDK 24:
- JEP 404: Generational Shenandoah (Experimental)
- JEP 450: Compact Object Headers (Experimental)
- JEP 472: Prepare to Restrict the Use of JNI
- JEP 475: Late Barrier Expansion for G1
- JEP 478: Key Derivation Function API (Preview)
- JEP 479: Remove the Windows 32-bit x86 Port
- JEP 483: Ahead-of-Time Class Loading & Linking
- JEP 484: Class-File API
- JEP 485: Stream Gatherers
- JEP 486: Permanently Disable the Security Manager
- JEP 487: Scoped Values (4th Preview)
- JEP 488: Primitive Types in Patterns, instanceof, and switch (2nd Preview)
- JEP 489: Vector API (9th Incubator)
- JEP 490: ZGC: Remove the Non-Generational Mode
- JEP 491: Synchronize Virtual Threads without Pinning
- JEP 492: Flexible Constructor Bodies (3rd Preview)
- JEP 493: Linking Run-Time Images without JMODs
- JEP 494: Module Import Declarations (2nd Preview)
- JEP 495: Simple Source Files and Instance Main Methods (4th Preview)
- JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
- JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm
- JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe
- JEP 499: Structured Concurrency (4th Preview)
- JEP 501: Deprecate the 32-bit x86 Port for Removal
## Changes in recent JDK 24 builds that may be of interest:
- JDK-8345015: Remove unused method lookup_time_t_function [Reported by JaCoCo]
- JDK-8344352: 32-bit builds crash after JDK-8305895 [Reported by JaCoCo]
- JDK-8344299: SM cleanup in javax.naming modules
- JDK-8343791: Socket.connect API should document whether the socket will be closed…
- JDK-8343001: Adjust XSLT and XPath Extension Function Property
- JDK-8341553: Remove UseCompactObjectHeaders extra CDS archives
- JDK-8333582: Update CLDR to Version 46.0
- JDK-8341975: Unable to set encoding for IO.println, IO.print and IO.readln
- JDK-8341551: Revisit jdk.internal.loader.URLClassPath.JarLoader after JEP 486
- JDK-8340359: Remove javax.naming.Context.APPLET
- JDK-8337199: Add jcmd Thread.vthread_scheduler and Thread.vthread_pollers diagnostic commands
- JDK-8313367: SunMSCAPI cannot read Local Computer certs w/o Windows elevation
- JDK-8341964: Add mechanism to disable different parts of TLS cipher suite
- JDK-8342075: HttpClient: improve HTTP/2 flow control checks
- JDK-8326949: Authorization header is removed when a proxy Authenticator is set on HttpClient
- JDK-8245545: Disable TLS_RSA cipher suites
- JDK-8338536: Permanently disable remote code downloading in JNDI
- JDK-8343004: Adjust JAXP limits
- JDK-8343020: (fs) Add support for SecureDirectoryStream on macOS
- JDK-8344882: (bf) Temporary direct buffers should not count against the upper limit on direct buffer memory
- JDK-8335912: Add an operation mode to the jar command when extracting to not overwriting existing files
- JDK-8319993: Update Unicode Data Files to 16.0.0
- JDK-8341566: Add Reader.of(CharSequence)
- JDK-8343881: java.lang.classfile.Attribute attributeName() method should return Utf8Entry
- JDK-8338021: Support new unsigned and saturating vector operators in VectorAPI
- JDK-8343150: Change URLClassLoader.getPermissions to return empty PermissionCollection
Note: A complete list of changes can be found here [12].
[10] https://jdk.java.net/24/
[11] https://jdk.java.net/24/release-notes
[12] https://github.com/openjdk/jdk/compare/jdk-24+21...jdk-24+28
# Topics of Interest
- Java 24 Performance Improvements & Deprecations
https://www.youtube.com/watch?v=oTc16DAMTqg
- Java 24 Language & API Changes
https://inside.java/2024/12/05/newscast-81/
- Java 24 Stops Pinning Virtual Threads (Almost)
https://inside.java/2024/11/21/newscast-80/
- Detoxifying the JDK Source Code
https://stuartmarks.wordpress.com/2024/12/12/detoxifying-the-jdk-source-c...
- Better Java Streams with Gatherers - JEP Cafe
https://inside.java/2024/11/26/jepcafe23/
- Java Language Futures - Fall 2024 Edition
https://inside.java/2024/10/30/devoxxbelgium-java-language-futures/
- Ask the Java Architects
https://inside.java/2024/11/14/devoxxbelgium-ask-architects/
- Pattern Matching in Java - Past, Present, Future
https://inside.java/2024/11/11/devoxxbelgium-pattern-matching/
- Monitoring Java Application Security with JDK tools and JFR Events
https://inside.java/2024/11/17/devoxxbelgium-security/
- Postcards from the Peak of Complexity
https://inside.java/2024/11/03/devoxxbelgium-complexity-peak/
- ZGC Automatic Heap Sizing #JVMLS
https://inside.java/2024/11/09/jvmls-zgc/
- Are Virtual Threads Going to Make Reactive Programming Irrelevant?
https://inside.java/2024/10/28/javazone-virtual-threads/
- A Sneak Peek at StableValue and SegmentMapper
https://inside.java/2024/10/24/devoxxbelgium-stablevalues/
- Release Your (Java) Projects Like OpenJDK
https://inside.java/2024/10/31/newscast-79/
- Advancing AI by Accelerating Java on Parallel Architectures
https://inside.java/2024/10/23/java-and-ai/
~
As always, ping me if you find any issues while testing your project(s) with the latest JDK early-access builds. And as the year-end is fast approaching, let me wish you all the best for the upcoming holidays. See you in 2025 with Java 24, JavaOne and Java 25!
PS: Please let me know if you don't want to receive these OpenJDK Quality Outreach updates anymore.
--David
1 year
Dec 18 deadline for WildFly 35 Final
by Brian Stansberry
Hi everyone,
We're planning to target WildFly 35 Final on Wednesday January 8.
To hit this target we need all PRs for changes that will go into 35 Final
to be **ready for merge by next Wednesday December 18**.
So in a bit over a week.
By ready for merge we mean with code review approvals by the relevant
people and with acceptable CI results.
We need things done by then in order to have time to merge them and do a
WildFly Core release before people go off for PTO.
If something critical comes up over the year end vacation period we can
handle PRs to fix it that are ready for merge by Thursday January 2. **No
one should plan now on using that Jan 2 deadline; it's only for responding
to unexpected events.** Many people will not be back from holidays that
first week of January. There will be no capacity to deal with a bunch of
changes. Get things done by Dec 18 or count on it waiting until WildFly 36.
Best regards,
--
Brian Stansberry
Principal Architect, Red Hat JBoss EAP
WildFly Project Lead
He/Him/His
1 year
