generated code and jigsaw modules

Remi Forax forax at univ-mlv.fr
Thu Oct 4 16:26:59 UTC 2018


----- Mail original -----
> De: "Richard Hillegas" <rhillegas at comcast.net>
> À: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> 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:
> 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.

you can use Lookup.defineClass.

> 
> Thanks,
> -Rick

cheers,
Rémi


More information about the core-libs-dev mailing list