override module with an alternative implementation in the child layer

[Milen Dyankov]

Thank you Alan,

that is what I originally thought. It's just your comment in the other
thread made me think there may be a possibility I was not aware of.

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?



On Mon, Jul 30, 2018 at 8:17 PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

> On 30/07/2018 10:16, Milen Dyankov wrote:
> > In response to a question posted on this list [1] some time ago, Alan
> > Bateman stated "You can override *any* module (except java.base) with an
> > alternative implementation in the child layer". Is that true for the
> > standard JDK modules? If so, is there any documentation / code samples
> that
> > explains how?
> >
> The previous thread didn't get into this but the other restriction is
> that you can't contain modules that export java.* APIs in custom layers
> (javax.* APIs are not an issue). I don't have time to give a detailed
> reply just now but look for the following in the javadoc of the
> ModuleLayer defineModulesXXX methods:
>
> "In addition, a layer cannot be created if the configuration contains a
> module named "java.base", a configuration contains a module with a
> package named "java" or a package name starting with "java.", or the
> function to map a module name to a class loader returns null or the
> platform class loader"
>
> -Alan.
>
>

-- 
http://about.me/milen