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

[David Lloyd]

On Mon, May 13, 2024 at 3:49 PM Ron Pressler <ron.pressler at oracle.com>
wrote:

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

I'm well aware of these arguments, as I was present when they were devised
(and have the scars - and jpms-spec-experts membership - to prove it). As I
said, I fully support the goal of integrity by default.

However neither of these points really addresses the problem at hand. In
particular, ReflectionFactory does not relate specifically to serializing
JDK classes; it presently provides access to serialization constructors and
(lately) the non-public serialization spec methods for *all* classes. It
does not address the problem of field access in any way.

While I understand that nobody likes the current JDK serialization strategy
(we don't like it either), we don't really have a workable alternative
*yet*. I've seen the seeds of some good ideas from Brian and others over
the years but there is nothing that we can point to and say "this is where
we are going to go with this". In the meantime there are several thousand
JDK classes, and many more thousands of user classes which are
`Serializable`. It is not feasible to ask the user to `--add-opens` every
single package containing such a class. It is also not feasible for every
general purpose library that contains a `Serializable` class to open their
packages containing serializable classes to the modules of every existing
serialization spec compliant framework. It will simply not work in
practice, and this is another hurdle preventing the modularization of the
ecosystem as a whole.

ReflectionFactory allows access to serialization facilities without any
access checking (other than the defunct SecurityManager checks). Perhaps
this class could gain some more methods, like this:

* `newGetterForSerialization(Field field)` - includes ability to access
`objectStreamFields` and `serialVersionUID`, or these could be separate
methods
* `newSetterForSerialziation(Field field)`

Does this seem workable?


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