Thanks, Alan. This is very helpful.
On 10/10/18 9:53 AM, Alan Bateman wrote:
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
