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.
Thanks,
-Rick
