Module in JDK image as platform module or loaded by application class loader?

[Alan Bateman]

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