Am 11.09.2015 14:29, schrieb Alan Bateman: [...]
Supporting dynamic languages and creating dynamic modules is very much an advanced topic at this time and there isn't support in the exported API for this. There is of course low-level support in the implementation and you'll find that Proxy and a few other areas that spin classes at run-time are using it in the current builds.
I will have a look. But this most certainly means we will have to change several parts of the code. We use our own class loaders in several areas, as well as runtime generated classes.
At this time, if you are spinning classes the same package/loader of existing modules then those generated classes will be members of the module. If you are spinning classes into new packages or different class loaders that don't have any modules defined to them then they will be in that loader's unnamed module.
generating classes using a new classloader is the standard for us. That is imho the case for our callsite caching, but I am very sure for groovy classes compiled and run at runtime. Since there will be several layers of code between the place that causes the compilation and execution as well as the place that does it I also currently see no way to add ourselves like a layer. It would require to be able to know the caller class/module or something like this. That is still an unsolved problem on the JVM for non-JDK code - imho.
bye Jochen -- Jochen "blackdrag" Theodorou blog: http://blackdragsview.blogspot.com/
