Closed vksiva closed 1 year ago
Thanks for reporting this. Indeed, we've solved this in the next release through https://github.com/jOOQ/jOOR/issues/67
In fact, no. CompileOptions
does not allow for overriding the ClassLoader
yet. Will look into this soon. There are tons of open questions when doing that, of course. The current approach allows for some additional visibility to be implemented, from the very location of where the class is being compiled. With arbitrary class loaders, this will no longer be true.
Further investigation needed.
The custom class loader feature has been implemented. But I will also implement a breaking change that avoids re-loading a previously compiled class by default. I don't think that's what anyone really wants. See #76
Hmm, no in fact #76 cannot be implemented. The current implementation prevents LinkageError
in some cases.
I will revert this change. Unfortunately, providing a custom ClassLoader
doesn't really help solve any problems in JDK 9+
This appears to be useful for jOOQ's code generator as well, including for:
A quick attempt at re-implementing this seems to work for jOOQ (whose code generation plugin creates its own URLClassLoader
). Perhaps I just made a mistake when implementing the tests at the time?
I'll try this again.
Hmm, no in fact #76 cannot be implemented. The current implementation prevents
LinkageError
in some cases.
I'm no longer running into these errors from: https://github.com/jOOQ/jOOR/issues/72#issuecomment-444077568
Perhaps that was a JDK bug, at the time?
Fixed for jOOR 0.9.15
Time for a release, too.
Expected behavior and actual behavior:
Using the example as presented in the README,
If the text has to be changed to "Hi World!" and the class is recompiled, the below code still prints "Hello World!"
One way to ensure the class gets recompiled is by using different classloaders during compile. Can we use a custom classloader for the Reflect.compile() method. It was raised in #64.
Steps to reproduce the problem:
Mentioned above.
Versions: