Unsafe and JPMS

[Alan Bateman]

On 19/01/2018 18:31, Jeremy Manson wrote:
> :
>
> 1) 
> testStaticsDiscovery(com.google.common.profile.HeapInspectorTest)java.lang.reflect.InaccessibleObjectException: 
> Unable to make field final jdk.internal.loader.URLClassPath 
> jdk.internal.loader.ClassLoaders$AppClassLoader.ucp accessible: module 
> java.base does not "opens jdk.internal.loader" to unnamed module 
> @3e11f9e9; did you mean 
> --add-opens=java.base/jdk.internal.loader=ALL-UNNAMED
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:345)
> at 
> java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:281)
> at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:176)
> at java.base/java.lang.reflect.Field.setAccessible(Field.java:170)
> at 
> com.google.common.profile.HeapInspector.getClassFields(HeapInspector.java:1234)
The class name hints that this is a HeapInspector walking the object 
graph. I assume it's not deliberately trying to hack the ucp field (btw: 
is the "did you mean ..." line a Google customization?)

The tool may have worked unchanged since JDK 1.4 but it now finds itself 
in a new world where there are modules that are trying to encapsulate 
their internals. In this case the java.base module does not want to open 
jdk.internal.loader (it's new in JDK 9 so this is why it is not open). 
This is the tension that is discussed here many times. All I'm saying is 
that the path for diagnostic tooling like this is the tool agent route. 
Tool agents get encapsulation busting powers at the cost of using tool 
APIs and being deployed as agents.

>
> If Launcher-Agent-Class is for executable JAR files, then that's 
> basically a non-starter for library classes, too.
>
> Also, it's worth pointing out that even if it feels wrong to you, it 
> has worked in the platform for many years - the cost I'm talking about 
> was written for Java 4, and hasn't needed to be changed since then.
>
> I also think that diagnostic code is a red herring here.  The OSS use 
> cases I pointed to are not in diagnostic code.
Sure, diagnostics tools are special but at least there are APIs and 
deployment options for these types of tools.

One of the libraries you listed seems to a serialization library. The 
conflict between legacy serialization and encapsulation is 
irreconcilable. While somewhat sad, this means that custom serialization 
libraries need to use the updated ReflectionFactory APIs in conjunction 
with unsafe. The API additions are in JDK 9 and were back-ported to JDK 
8u  to make it easier for serialization libraries that want to compile 
to JDK 8. I can't tell if the library you listed has been updated to use 
these APIs or not.

-Alan