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

[Ron Pressler]

> On 6 Jun 2024, at 18:37, David Lloyd <david.lloyd at redhat.com> wrote:
> 
> Just bumping this one more time. I intend to start by opening a JIRA to add the two proposed methods to `ReflectionFactory`, and go from there. I guess that we might need a JEP for the proposed serialization restrictions, which is going to be considerably more involved, so I'm putting that off as a second step for now, pending further discussion.


Hi. 

Seven years before the upcoming delivery of JEP 471 we [announced that the world of accessing JDK internals would be coming to an end](https://openjdk.org/jeps/260). Four years later, the JDK [started enforcing that](https://openjdk.org/jeps/403), but to give extra time to laggards who have not yet adapted to either refraining from accessing internals or instructing their users on the proper configuration of the JDK to allow doing so, we left some unsupported mechanisms in place to temporarily allow hacking around the restrictions until they can properly adapt. Now, three years later, we're starting the process of removing the temporary hacks, although we don't yet know how long the process should last.

My first question is, how many more years do you think we should wait for libraries to finish the process by which they either refrain from accessing internals or instruct their users on the proper configuration that allows them to do so? Knowing how long we should wait for the libraries that have not yet finished their adaptation in the past seven years, and how far along they are in the process, could help inform how long we should wait until the actual removal of Unsafe.

My second question has to do with the consideration that any serialization procedure should no longer bypass constructors (at least not without `--add-opens`, that is). I'd be interested to know about the difficulties serialization libraries have encountered in their process of migrating away from accessing internals and toward custom serializers for JDK classes, such as what public constructors are missing. This would help us identify what constructors we should add to support serialization that doesn't violate integrity.

— Ron