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
