<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><span style="font-family:Arial,Helvetica,sans-serif">On Fri, May 3, 2024 at 10:12 AM Mark Reinhold <<a href="mailto:mark.reinhold@oracle.com">mark.reinhold@oracle.com</a>> wrote:</span><br></div></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><a href="https://openjdk.org/jeps/471" rel="noreferrer" target="_blank">https://openjdk.org/jeps/471</a><br>
<br>
  Summary: Deprecate the memory-access methods in sun.misc.Unsafe for<br>
  removal in a future release. These unsupported methods have been<br>
  superseded by standard APIs, namely the VarHandle API (JEP 193,<br>
  JDK 9) and the Foreign Function &amp; Memory API (JEP 454,<br>
  JDK 22). We strongly encourage library developers to migrate from<br>
  sun.misc.Unsafe to supported replacements, so that applications can<br>
  migrate smoothly to modern JDK releases.<br></blockquote><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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`.</div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif"><br></div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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`.</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div></div><div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">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.</div><br></div><div><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Thanks!</div><br></div></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">- DML • he/him<br></div></div></div>