Thank you for the clarification Alan, it seams ALL-DEFAULT does not work with jlink but that is OK as I can easily find those modules while running my assembly tool and pass the list to jlink. The only difference between what I find and what you posted (I assume 7 was a typo as your list contains 9 modules) is that there seems to be no ` java.net.http` module (at least not among the 99 modules shipped in 10.0.1 that I'm experimenting with)
Thanks for your help. It's much appreciated. On Tue, Jul 31, 2018 at 2:20 PM Alan Bateman <alan.bate...@oracle.com> wrote: > On 30/07/2018 11:41, Milen Dyankov wrote: > > : > > > > So am I right to assume that any application server like software is > > expected to always run on top of all standard JDK modules that export > > "java.*" packages? I mean, say there is an application server that runs > on > > top of "minimal" JPMS created with jlink. If the base layer of that > > application server does not have "java.sql" for example, there is > > essentially no way for it to load it dynamically, when a JAR or WAR that > > needs it is deployed, correct? > > > One thing to say is the restriction on the java.* class name space is > rooted in security and has been in the Java SE API specification for > many releases. The VM enforcement around this goes back to JDK 1.2 at > least. The specification was relaxed in Java SE 9 to allow java.* > classes be defined to the platform class loader but going further, to > allow java.* classes be defined by other class loaders, would require > significant effort. > > Aside from java.base, there are 7 modules in Java SE with java.* APIs: > > java.datatransfer > java.desktop > java.instrument > java.logging > java.management > java.net.http > java.prefs > java.rmi > java.sql > > The long standing specified restriction on the java.* class name space > and the matching restrictions in the ModuleLayer API, mean that you > cannot load (or override) these 7 modules in a child layer created by > defineModulesXXX APIs. > > In your case, the main application (container / app server) doesn't > transitively require java.sql so this module is not in the boot layer. > It can't dynamically load it (because it contains a java.* classes) so > it has ensure that the above 7 modules are in the boot layer in order to > support dynamically loading of application modules that might require > one or more of these modules. In JEP 261 we document --add-modules > ALL-DEFAULT for this purpose: > > "As a special case at run time, if <module> is ALL-DEFAULT then the > default set of root modules for the unnamed module, as defined above, is > added to the root set. This is useful when the application is a > container that hosts other applications which can, in turn, depend upon > modules not required by the container itself." > > Could you use that? > > -Alan > -- http://about.me/milen
