override module with an alternative implementation in the child layer
Alan Bateman
Alan.Bateman at oracle.com
Tue Jul 31 12:20:02 UTC 2018
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
More information about the jigsaw-dev
mailing list