New candidate JEP: 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal

[David Lloyd]

On Fri, May 3, 2024 at 10:12 AM Mark Reinhold <mark.reinhold at oracle.com>
wrote:

> https://openjdk.org/jeps/471
>
>   Summary: Deprecate the memory-access methods in sun.misc.Unsafe for
>   removal in a future release. These unsupported methods have been
>   superseded by standard APIs, namely the VarHandle API (JEP 193,
>   JDK 9) and the Foreign Function & Memory API (JEP 454,
>   JDK 22). We strongly encourage library developers to migrate from
>   sun.misc.Unsafe to supported replacements, so that applications can
>   migrate smoothly to modern JDK releases.
>

We have a serialization library called JBoss Marshalling which performs
serialization and object cloning. This library is used extensively by our
products. The field values of the objects to be serialized are presently
accessed by this library with Unsafe.

I have experimentally replaced these usages with accessors (presently based
on `field.setAccessible(true)` plus `Lookup.unreflectGetter/Setter`), and
this has exposed a usability roadblock in that every single JDK (or other
module) package which contains a serializable class must be individually
configured for access using `--add-opens`.

While I believe that it is important for users to be able to opt in to any
unsafe access, it is not feasible to ask for users to do so on a
package-by-package basis for a general-purpose serialization library.
Conceivably every package containing a Serializable class would have to be
included. Notably, `Object*Stream` is exempt from this problem due to being
located in `java.base`.

Is there some supported or supportable way that a module (or unnamed
modules) can acquire broad powers to open any package using only a single
command-line switch? For example, using the restricted-API mechanism
somehow? This would preserve "opt-in" but also bypass the practical
limitations for users, in much the same way that FFM would force users to
opt in, with many of the same risks AFAICT.

I'm open to other ideas as well. But this does seem like a significant
roadblock to me, which would prevent our products from moving to 23 or
later.

Thanks!

-- 
- DML • he/him
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/jdk-dev/attachments/20240513/ddcf0e45/attachment-0001.htm>