generated code and jigsaw modules

[Richard Hillegas]

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
>
>
>
>
>