Unsafe and JPMS

[Jeremy Manson]

Hey folks,

I know this has come up before, but I wanted to revive the question.  As we
play more and more with JPMS and Java 9, we're finding more and more places
where Unsafe is now the only feasible way to achieve what we want to
achieve.

The big use case is, of course, access to the internals of modularized
libraries in ways that would have used standard reflection in Java 8 and
earlier, but for which we now fail with an exception.

The answer of adding command line flags doesn't really work for general
purpose libraries.  If I want to do this in (for example) Guava, asking
every Guava user to add add-opens on the command line is a complete
non-starter.  Many people have no idea what libraries they are using.

The answer of creating an agent is also a non-starter for similar reasons.

The answer of using privateLookupIn assumes that you have access to or
control over the target class, which is often not the case, especially if
you are introspecting into JDK internals.

As people within Google try Java 9, this is coming up in quite a bit of our
infrastructure, especially in diagnostic code.  The latest place I've found
it was a tool that printed out / counted the number of objects reachable
from a root object; it died when it got into a JDK library.  I've noticed
quite a few people using Unsafe as a workaround in OSS libraries, too: Netty
<https://github.com/netty/netty/issues/6269>, Kryo
<https://github.com/EsotericSoftware/kryo/issues/543>, cglib
<https://github.com/cglib/cglib/issues/93>.

So... OpenJDK has this commitment not to replace Unsafe without providing
supported replacements for its functionality and a transition period.  Does
that include the functionality that Unsafe can break module encapsulation?

Thanks!

Jeremy