override module with an alternative implementation in the child layer

[Milen Dyankov]

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.Bateman at 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