generated code and jigsaw modules

[Alan Bateman]

On 04/10/2018 17:10, Richard Hillegas wrote:
> I am looking for advice about how to tighten up module encapsulation 
> while generating byte code on the fly. I ask this question on behalf 
> of Apache Derby, a pure-Java relational database whose original code 
> dates back to Java 1.2. I want to reduce Derby's attack-surface when 
> running with a module path.
>
> First a little context: A relational database is an interpreter for 
> the SQL language. It converts SQL queries into byte code which then 
> runs on a virtual machine embedded in the interpreter. In Derby's 
> case, the virtual machine is the Java VM and the byte code is simply 
> Java byte code. That is, a Derby query plan is a class whose byte code 
> is generated on the fly at run time.
>
> I have converted the Apache Derby codeline into a set of jigsaw 
> modules: https://issues.apache.org/jira/browse/DERBY-6945. 
> Unfortunately, I had to punch holes in the encapsulation of the main 
> Derby module so that the generated query plans could call back into 
> the Derby engine. That is because, by default, generated query plans 
> load into the catch-all, unnamed module. Note that all of these 
> generated classes live in a single package which does not belong to 
> any named module.
>
> 1) Is it possible to load generated code into a named module?
>
> 2) Alternatively, can someone recommend another approach for 
> preserving module encapsulation while generating classes on the fly?
>
> I would appreciate any advice or examples which you can recommend.

There are a couple of places in the JDK where we spin bytecode into 
modules that are created at run-time. One example is in the Nashorn and 
was presented by MIchael Haupt at JVMLS 2017 [1]. There's a lot in that 
so a simpler example to look at is in the XML transformation code [2] 
where there is a module created at run-time for each translet. The 
module is fully encapsulate except for an entry point that it exports to 
the java.xml module in the parent module layer. In turn, the java.xml 
exports one of its internal packages to the translet module to allow 
what may be equivalent to your generated code calling back into the 
Derby engine.

-Alan

[1] https://www.youtube.com/watch?v=Zk6a6jNZAt0
[2] 
http://hg.openjdk.java.net/jdk/jdk/raw-file/tip/src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TemplatesImpl.java