On 06/07/2017 13:03, Langer, Christoph wrote:
Hi there,
for our JDK 9 image the jtreg test jdk/modules/etc/VerifyModuleDelegation has
unveiled a problem.
The issue is that we introduced a few modules that are defined as a platform
module. One of these modules requires jdk.attach which is neither boot nor
platform. The code within the module that requires jdk.attach seems to work
since the platform class loader is able to load jdk.attach classes because it
delegates to the application class loader.
This is special delegation that is needed in order to support upgraded
modules that depend on modules on the application module path.
However, VerifyModuleDelegation is not satisfied with the fact that the
loader of our custom module isn't the loader of jdk.attach or one of its
ancestors.
Now, for me the question is how to solve this correctly? I currently see 3
options:
1. move jdk.attach (and hence jdk.internal.jvmstat ) to the platform modules
The attach API is a tool API and tool APIs have traditionally had their
classes defined to the app class loader (by way of putting tools.jar on
the class path path). So I don't think this should be changed.
2. remove our custom modules from the list of platform modules in order to get
them under the application class loader
This seems the right option but would be interesting to know why it was
added to PLATFORM_MODULES in the first place.
3. leave the class loaders of the modules alone, remove the requires statement
from module-info and implement a Service (Loader) that can be implemented in
our jdk.attach version
That would work but seems unnecessary indirection unless the usage lends
itself to services.
-Alan
