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

[Ron Pressler]

The draft JEP, Integrity by Default (https://openjdk.org/jeps/8305968), which covers the general strategy guiding us in this JEP and others, also covers the recommended practice for libraries under integrity by default. It includes what we’ve recommended to serialization libraries since JDK 9. I’ll summarise the recommendations here:

1. Client code should grant the serialization library access to its private data either programmatically (by passing a MethodHandles.Lookup, e.g. in a class initializer) or declaratively by opening the module to the serialization library in module-info.java.

2. When serializing JDK classes, the serialization library can take advantage of sun.reflect.ReflectionFactory, which has been left unencapsulated precisely for that purpose.

However, in the long term serialization libraries are advised to migrate away from any direct access of fields, as the practice is inherently dangerous: it bypasses data validation done in the constructor. Deserialization in particular should use constructors, which is easy for collections and records, and ask users to register class-specific serializers that call constructors for other kinds of classes.

Explicitly granting deep reflective access — either declaratively or programmatically — is useful to express the risk inherent to allowing library code, which is unaware of the specific invariants of a class, directly set a class’s fields while bypassing its constructors. A more coarse-grained permission poses a usability challenge, as it makes it hard to inspect which classes are exposed to which risks.

— Ron

> On 13 May 2024, at 19:46, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> 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