| [Xbase] Classloading in XbaseInterpreter [message #1804214] |
Wed, 20 March 2019 11:06  |
Eclipse User |
|
|
|
Hi,
I'm writing an interpreter for an Xbase-based DSL and would like to support loading classes from the same Java project as the DSL file. That way I can mix Java code and DSL code. I have a ClassLoader that uses the classpath entries of the Java project and it works fine. The next step is to react to changes to Java project classes and re-instantiate the classloader, so the interpreter doesn't use old classes. This also works in principle, however, some class caching mechanism prevents it from working properly. Even though my classloader correctly reloads changed classes, Xtext's ClassFinder class (as used by XbaseInterpreter and JavaReflectAccess) uses Class.forName(String, boolean, ClassLoader) and it apparently (according to https://blog.hargrave.io/2007/09/classforname-caches-defined-class-in.html) has its own caching that reuses obsolete classes.
I've been able to replace JavaReflectAccess with my own class (since it is injected I can override it in my Guice module) and make it use a custom ClassFinder that uses ClassLoader.loadClass directly (instead of Class.forName), but XbaseInterpreter has another instance of ClassFinder that cannot easily be replaced, since it is not injected, but created using new, is private and accessed directly in many methods. So although my approach seems to work, now XbaseInterpreter uses (directly and indirectly through JavaReflectAccess) two ClassFinder instances with different class loading logic and that seems wrong, so I wonder what to do. The best would be to have the XbaseInterpreter use the same instance as JavaReflectAccess, or allow the creation of the its own ClassFinder instance to be customised (e.g. in an overridable getClassFinder method, like JavaReflectAccess does).
Any suggestions?
Regards,
Hallvard
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.31068 seconds
Home