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
