generated code and jigsaw modules

[Richard Hillegas]

On 10/4/18 9:45 AM, Alan Bateman wrote:
> 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
Thanks, Alan. I will study this example. Cheers!
>
> [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
>