Not sure if folks saw this, but it's possibly going to be relevant for our
test suite since I think we're still using security manager in deprecated
mode?

---------- Forwarded message ---------
From: David Delabassee <david.delabas...@oracle.com.invalid>
Date: Fri, Dec 13, 2024 at 9:17 AM
Subject: JDK 24 Feature Freeze | Permanently Disabling the Security Manager
To: d...@commons.apache.org <d...@commons.apache.org>


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-8341551: Revisit jdk.internal.loader.URLClassPath.JarLoader after JEP
486
- 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-8340359: Remove javax.naming.Context.APPLET
- 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-8342075: HttpClient: improve HTTP/2 flow control checks
- JDK-8326949: Authorization header is removed when a proxy Authenticator
is set on HttpClient
- 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-8245545: Disable TLS_RSA cipher suites
- JDK-8319993: Update Unicode Data Files to 16.0.0
- JDK-8341566: Add Reader.of(CharSequence)
- JDK-8335912: Add an operation mode to the jar command when extracting to
not overwriting existing files
- 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-code/

- 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/

- ZGC Automatic Heap Sizing #JVMLS
https://inside.java/2024/11/09/jvmls-zgc/

- Postcards from the Peak of Complexity
https://inside.java/2024/11/03/devoxxbelgium-complexity-peak/

- Release Your (Java) Projects Like OpenJDK
https://inside.java/2024/10/31/newscast-79/

- 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/

- 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

Reply via email to