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