H Paul, Thank you very much for your input!
On Wed, Jul 3, 2019 at 5:30 PM Paul Bjorkstrand <[email protected]> wrote: > ...From what I know of GraalVM/native-image, the biggest hurdles will be with > classloading (lazy load/hiding bundle-private classes) and reflection... Yes out of the list at [1] that's what I'm mostly seeing in my experiments. Figuring out what's causing trouble when adding third-party libraries can be quite hard as native-image error messages are far from obvious to me, so I've been going in very small steps and that helps. > ...The nature of how Felix/OSGi hides nonpublic classes (like you stated #4 on > SLING-8556) would make it extremely difficult to get this working without > major changes... yes, and it looks like just having classes embedded in bundles is a problem at build time, so I'm not sure if Felix Connect would help much (but happy to be proven wrong on that one). > > Reflection can be worked around, by providing a list of what can be found > by reflection... Yes and the tracing agent mentioned at SLING-8556 helps with that. > ....It is likely that the entirety of Sling would need to > be able to run without being inside an OSGi container, before you can get > native-image to work properly.... Agreed - for now I'm focusing on getting a useful subset of Sling to run as a native image, using static wiring of the required components. I have moved my code to https://github.com/apache/sling-whiteboard/tree/master/graalvm - large parts of it are still Very Ugly (TM), for now I've been able to run the SlingRequestProcessor in a degraded way, with lots of shortcuts and mocks - but I do have an HTTP server that starts in a few msec and runs some Sling core code. I'll work on fleshing out the SlingRequestProcessor environment next, to make the example more realistic - but I'm not shooting to run the whole of Sling in a native image, just some small parts as mentioned. -Bertrand [1] https://github.com/oracle/graal/blob/master/substratevm/LIMITATIONS.md
