generated code and jigsaw modules

Richard Hillegas rhillegas at
Thu Oct 4 21:55:27 UTC 2018

On 10/4/18 9:26 AM, Remi Forax wrote:
> ----- Mail original -----
>> De: "Richard Hillegas" <rhillegas at>
>> À: "core-libs-dev" <core-libs-dev at>
>> Envoyé: Jeudi 4 Octobre 2018 18:10:13
>> Objet: generated code and jigsaw modules
>> 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.
> you can use Lookup.defineClass.
Thanks, Rémi. That gives me something to google up. Cheers!
>> Thanks,
>> -Rick
> cheers,
> Rémi

More information about the core-libs-dev mailing list