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

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Langer, Christoph
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. 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
2. remove our custom modules from the list of platform modules in order to get them under the application class loader
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

To get on the right way here I probably understand too little of the implications of a module being "Platform". I understand that platform modules don't have all permissions by default such as modules loaded by the boot loader. However, there are some differences and there were reasons why we elevated our modules to "platform", I think it had to do something with caller sensitive calls or other authentication checking mechanisms.

So, probably solution 1.) would be the easiest but I don't know if it is a good idea and we lose some compatibility with OpenJDK. 2.) I have to check again where the problems were and 3.) Seems a bit complicated and would unnecessarily break the coupling of modules via module-info.

So, I'm hoping to get some advice here :)

Thanks in advance and best regards
Christoph

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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
Loading...