3 ms·
> If your application doesn't do bytecode generation or instrumentation at runtime I believe it also has trouble with reflection involving class names that are
by xienze 8y ago
> If your application doesn't do bytecode generation or instrumentation at runtime
I believe it also has trouble with reflection involving class names that aren't effectively constant at compile-time. So with that and the other limitations, there's a whole lot you can't do. Hopefully they can resolve that.
- calcifer 8y ago> reflection involving class names that aren't effectively constant at compile-time Can you give an example?
- xienze 8y agoSure, just about any project that has the concept of plugins. At runtime the code looks for plugin instances by searching for, e.g., META-INF/services/<interface_name> on the classpath. Inside that file (or files) you have implementation class names, which are collected and instantiated.
- the8472 8y agoI don't think they intend to solve that because the cases that it can't handle are basically application servers, plugin-based applications and the like. They violate the closed world assumption which graal's native image builder relies on. Those are better served by a full JVM, optionally boiled down with jlink or with AOT compilation for faster startup, and the JEP that was mentioned upthread.
- pjmlp 8y agoThis limitation also exists in other languages that have reflection. In .NET Native and Lisp for example, you need to list code that should be kept around and not removed by the linker. It is not an easy problem to sort out in some kind of automatic way.