generated code and jigsaw modules

[Alan Bateman]

On 10/10/2018 16:37, Richard Hillegas wrote:
> :
>
> java.lang.invoke.MethodHandles.lookup().defineClass(generatedClassBytes)
>
> This approach does indeed put the generated class where I want it: 
> inside the Derby engine module. Unfortunately, the ClassLoader of the 
> generated class is the application class loader. I can't figure out 
> how to force the generated class to use the custom ClassLoader instead.
MethodHandles.lookup() creates a Lookup to the caller of the method so I 
assume you must be calling it from Derby code on the class path. If you 
want the class generated in the same runtime package as the code loaded 
from the database then you'll need to get a Lookup object to a class in 
that runtime package, perhaps with privateLookupIn.

>
> Alan's approach is a bit more complicated. It involves following the 
> pattern in com.sun.org.apache.xalan.internal.xsltc.trax.TemplatesImpl. 
> It involves generating a temporary module for each generated class and 
> then adding more export directives to the engine module so that the 
> generated module can call back into the engine. I have to say I'm a 
> little confused about the implications of slow memory leaks with this 
> approach. I don't know what happens to these generated modules and 
> export directives when the generated class is garbage-collected.
>
> More immediately, however, I am up against the same problem which 
> plagues Rémi's approach: how do I get the generated module to resolve 
> classes in the custom ClassLoader? More specifically, I am stuck 
> trying to get the generated module to require the user-written 
> modules, that is, the user-written jar files. What I am missing is the 
> ability to retrieve the module names of these jar files so that I can 
> craft requires directives. The only way I know to get a module name is 
> to use ModuleFinder.of(Path...). Unfortunately, the Path interface is 
> an abstraction for file systems and is not a good fit for locating a 
> blob of bytes stored inside a database.
My mail wasn't suggesting an approach, I was just pointing out an 
example of code in the JDK that creates a dynamic module to encapsulate 
generated code. It just happens that there is one class in that module.

As regards classes in the database then it would require developing your 
own ModuleFinder that can find modules in the database. There was an 
example on jigsaw-dev recently where someone was looking for a 
ModuleFinder to find modules in WAR files [1] which might be useful to 
get an idea on what is involved.

-Alan

[1] 
http://mail.openjdk.java.net/pipermail/jigsaw-dev/2018-September/013924.html