sun.misc.Unsafe will be deprecated with Java 22

[laeubi]

org.eclipse.osgi.internal.url.MultiplexingFactory uses sun.misc.Unsafe what will be deprecated with Java 22:

Greetings!

We are starting 2024 with JDK 22 as it has just entered Rampdown Phase 2 [1]. And with the initial JDK 22 Release Candidates now less than 2 weeks away (Feb. 8th) [2], it is time to shift our attention to JDK 23.

After multiple rounds of incubations and preview, the Foreign Function & Memory API is becoming standard and permanent in JDK 22. If we put its 'Function' angle aside, this API also offers a standard and secure way to access off-heap API. And that brings us to the heads-up below 'Deprecate the memory-access methods in sun.misc.Unsafe for removal in a future release' as developers still using sun.misc.Unsafe for accessing memory are strongly encouraged to start preparing their plans to migrate away from those unsafe methods.

[1] https://mail.openjdk.org/pipermail/jdk-dev/2024-January/008675.html
[2] https://openjdk.org/projects/jdk/22/

Heads-up: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal in a Future Release

The effort focused on enforcing the integrity of the Java platform [3] continues! The next phase in that long but important initiative will most likely target the sun.misc.Unsafe API used for accessing memory. Those methods alone represent 79 methods out of the 87 sun.misc.Unsafe methods!

This draft JEP [4] outlines the plan to deprecate for removal the sun.misc.Unsafe Memory-Access methods, the reasons, and the standard alternatives. As the draft plan suggests, the first step will be to deprecate all memory-access methods (on-heap, off-heap, and bimodal) for removal. This will cause compile-time deprecation warnings for code that refers to the methods, alerting library developers to their forthcoming removal. In addition, a new command-line option will allow users to receive runtime warnings when those methods are used. This command-line will help users to assess if their codebase uses those unsafe API to access memory. It should be mentioned that other tools such as JFR and jdeprscan can also be used to detect the use of those deprecated APIs.

Library developers are strongly encouraged to migrate from sun.misc.Unsafe to the supported replacements, so that applications can migrate smoothly to modern JDKs. The initial step will be to conduct investigations to understand if, how, and where sun.misc.Unsafe methods are used to access memory.

[3] https://openjdk.org/jeps/8305968
[4] https://openjdk.org/jeps/8323072

--- SNIP ---

As usual, let us know if you find any quirks while testing your project(s) with the latest JDK early-access builds.

--David

So I think it is a good opportunity to check with the java-devs how we can get rid of it in a"standard" way, @tjwatson can EF maybe "officially" get in touch with Oracle to get our concerns/demands addressed?

[tjwatson]

org.eclipse.osgi.internal.url.MultiplexingFactory uses sun.misc.Unsafe what will be deprecated with Java 22:

The use of Unsafe there will get no support from the Java team, regardless of what the future plans are for replacements offered for Unsafe. We are basically breaking the modularity rules there. Something the Java team will never add API for in Java. Moving forward it becomes increasingly more difficult to properly support Multiplexing URL factory stuff and the specification of OSGi will just have to deal with that. But it means nested framework instances will not be able to have their own URL factory registrations.

See osgi/osgi#226

[github-actions]

This issue has been inactive for 180 days and is therefore labeled as stale.
If this issue became irrelevant in the meantime please close it as completed. If it is still relevant and you think it should be fixed some possibilities are listed below.
Please read https://github.com/eclipse-equinox/.github/blob/main/CONTRIBUTING.md#contributing-to-eclipse-equinox for ways to influence development.

[HannesWell]

I think this is still relevant, even tough it looks like there is no good solution.