Open Daniel-Alievsky opened 2 years ago
I understand that there is workaround like the following:
class JepTools {
static {
ClassLoader contextClassLoader = Thread.currentThread().getContextClassLoader();
if (contextClassLoader == null) {
Thread.currentThread().setContextClassLoader(JepTools.class.getClassLoader());
}
}
...
}
But you understand that this is a last resort and a highly undesirable solution for a generic library.
This is a duplicate of #401 and a fix has already been written and will be included in the next release of Jep.
In the meantime if it is unnacceptable to set a context classloader for your thread you could also set a custom ClassEnquirerer in your JepConfig that uses a different ClassLoader.
Ok, I prefer to wait for a new release. When, approximately, are you going to do this?
I have added a Roadmap to the wiki with our release plans. Next release will come out around October 2022.
Hello! I successfully used JEP from usual Java environment, where JVM is called via "java.exe" (Windows-8).
But really I need to use it from little other environment: C++ server, which initializes JVM itself (JNI technology). And I see that my simplest test does not work.
This is my code:
This is the result:
It seems to be your bug. Below is your code, that I found in debugger:
You think that classloadersToTry contains only non-null values, but it is not so:
When JVM is started not by normal java.exe, but via JNI, Thread.currentThread().getContextClassLoader() will be null by default.
Could you fix this?