>From what I know of GraalVM/native-image, the biggest hurdles will be with classloading (lazy load/hiding bundle-private classes) and reflection. 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.
Reflection can be worked around, by providing a list of what can be found by reflection, so native-image can make that statically available to the stripped down application. Removing reflection and dynamic class loading means it would be impossible (or nearly so) to make running application bundle changes. At that point, you might as well be not using OSGi at all. The idea of PojoSR is interesting, though, and (as Robert said) would be a good starting point. 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. That effort, while probably huge, may be easier than getting Felix to work with native-image. Paul Bjorkstrand On Wed, Jul 3, 2019 at 6:08 AM Robert Munteanu <romb...@apache.org> wrote: > On Wed, 2019-07-03 at 13:00 +0200, Bertrand Delacretaz wrote: > > Hi Robert, > > > > On Wed, Jul 3, 2019 at 12:25 PM Robert Munteanu <romb...@apache.org> > > wrote: > > > ...Have you considered using FelixConnect [1] > > > instead of the OSGi mocks?... > > > > Yes that's one of the options as well. > > > > I haven't found docs or tests for that module however so I'm a bit > > wary of using it, but I'll keep it in the back of my mind! > > Oak has a module using Felix Connect - back when it was called PojoSR. > > https://github.com/apache/jackrabbit-oak/tree/trunk/oak-pojosr > > If you decide to try it out it can be a good starting point. > > Thanks, > > Robert > >
