Module in JDK image as platform module or loaded by application class loader?
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
Re: Module in JDK image as platform module or loaded by application class loader?
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
Re: Use classes in unnamed module that are also contained in a JDK platform/runtime module
Hi Christoph, On 7/4/2017 12:02 AM, Langer, Christoph wrote: I have some piece of software that we ship as a jar file and which will hence run on a JDK 9 in the unnamed module. However, this jar file contains a package that is also contained in our JDK image in a module that is always part of the runtime. It would be remiss of me if I didn't ask for some details about why this scenario has arisen. From "always part of the runtime", I would have guessed the package is in java.base, but you also mention "our JDK image" so perhaps the package is in a module that SAP always jlinks in? Alex
RE: Use classes in unnamed module that are also contained in a JDK platform/runtime module
Hi Alex, > On 7/4/2017 12:02 AM, Langer, Christoph wrote: > > I have some piece of software that we ship as a jar file and which > > will hence run on a JDK 9 in the unnamed module. However, this jar > > file contains a package that is also contained in our JDK image in a > > module that is always part of the runtime. > > It would be remiss of me if I didn't ask for some details about why this > scenario has arisen. From "always part of the runtime", I would have > guessed the package is in java.base, but you also mention "our JDK > image" so perhaps the package is in a module that SAP always jlinks in? Thanks for your interest in the details. Here it is: We have a separate module that exposes an augmenting SAP specific API which is publicly exported. This module is part of our JDK image. And it in turn pulls a few other modules with the implementing classes and packages. And then we ship a few tools and services apart from the JDK. Some of these are Eclipse based, some of these are standalone. And parts of these tools use the basic classes which are also observable in the JDK. But they need to be there as our tooling should run on any JDK, not only ours. I think Eclipse-wise we are good, at least when Eclipse runs on Java 8. With the Eclipse classloading, we get the classes out of the plugins. However, since Eclipse is not really mature yet for Java 9, I didn't test there so far. And for the standalone apps, I probably need to look into implementing some custom classloader. I'll try with Alan's suggestions (thanks Alan) but didn't find the time yet. Thanks & Best regards Christoph
