Hi, I thought winegrower was the one targetting native support by design - and already has its arthur knight https://geronimo.apache.org/arthur/winegrower-knight.html - and Karaf 5 the opposite: aggregation and optimization of heterogeneous runtimes in a single JVM. Did I miss anything?
Romain Manni-Bucau @rmannibucau <https://twitter.com/rmannibucau> | Blog <https://rmannibucau.metawerx.net/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/application-development/java-ee-8-high-performance> Le mar. 8 févr. 2022 à 13:09, Łukasz Dywicki <l...@code-house.org> a écrit : > I did have some small attempts turning basic apps into native images and > I believe it is very good idea, yet I am not sure if Karaf (or OSGi per > say) is ready for that. I am glad you are opening this topic as I am > interested in anyone succeeded in making a native image which can keep > OSGi semantics. ;-) > I think problem with native images lies somewhere else than command line > handling, as we rely on jansi and jline which are used in other > ecosystems which are deep in native compilation. > Because Karaf stuff is promoting modulith approach you might have > multiple apps and services running at the same time. This means that > native compilation might be more complicated as some of classes will > obviously get shared across multiple places, the asynchronous nature of > service activation might result in scenarios where you simply have to > "warm up" app long enough so you catch all places which are touched by > java reflection api. Its also possible that without valid preparation > you will be pulling some libraries in different versions. I am not sure > how graal is handling that. Given that even netty could produce troubles > with native image I am a little bit afraid how verbose is preparation > for more complicated applications. > > Best, > Łukasz > > On 7.02.2022 08:14, Bernd Eckenfels wrote: > > Hello, > > > > I wonder are there any plans for native image and tree shaking for > karaf5? > > > > Especially I think we need a shell framework (like quarkus/picocli) > which allows a fast stand-alone cli. At least if karaf plans to play in > this space. I like the OSGi console command abstraction, so it would be a > good candidate if one can proceed to write (Developer and ops) commands > this way and then compile it. > > > > This could even abstract away some of the more arcane to use maven steps > (archetype) and add new things like development server or even client.sh. > > > > Gruss > > Bernd > > > > > > -- > > http://bernd.eckenfels.net > > >
