generated code and jigsaw modules

Richard Hillegas rhillegas at
Thu Oct 4 16:10:13 UTC 2018

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: 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.


More information about the core-libs-dev mailing list