RFR: 8277013: Allow creation of module graphs without defining modules to the VM

[Alan Bateman]

On Thu, 11 Nov 2021 14:53:13 GMT, Ivan Ristović <duke at openjdk.java.net> wrote:

> Related JBS issue: https://bugs.openjdk.java.net/browse/JDK-8277013
> 
> The GraalVM Native Image module support must create the runtime boot-module layer at image build time; module instances created at build time need to reflect module relations at runtime, i.e., their opens, reads, and exports. To achieve this, we had to duplicate and modify a significant portion of the module synthesis methods from the JDK. The GraalVM PR that demonstrates this duplication can be found at:
>   ​https://github.com/oracle/graal/blob/9bfa3a312d7d0309eb014d52e49afd7136d9e77e/substratevm/src/com.oracle.svm.hosted.jdk11/src/com/oracle/svm/hosted/ModuleLayerFeature.java#L269
> 
> The hard-to-maintain code duplication is necessary as synthesizing module graphs in the JDK unconditionally defines modules to the VM which causes an error due to module redefinition. For example, methods `System.defineModule`, `ModuleLayer` factories and constructor, and `Module` constructor unconditionally update the VM state. All these methods eventually reach the `Module` constructor or the `Modules.defineModules` method.
> 
> We propose that the `Module` constructor and the `Modules.defineModules` conditionally update the VM state (similarly to 'Module.implAddReads`). The JDK would call these methods so they update the VM state and GraalVM Native Image would call them without updating the state.

GraalVM native image is a really interesting PoC but not clear to me that the JDK should be adding non-public constructors for code outside of the JDK to call.

If we do need to do something here then it will require cleanup so that it is consistent with the existing code.

-------------

Changes requested by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/6356