generated code and jigsaw modules
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 . There's a lot in
> that so a simpler example to look at is in the XML transformation code
>  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.
Thanks, Alan. I will study this example. Cheers!
>  https://www.youtube.com/watch?v=Zk6a6jNZAt0
More information about the core-libs-dev