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
