generated code and jigsaw modules
Richard Hillegas
rhillegas at comcast.net
Thu Oct 4 21:57:11 UTC 2018
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
>
More information about the core-libs-dev
mailing list