The other limitation in native-mode to be aware of is the reflection : it's
all doable but needs
some opt-in so that the reflection informations can be included in the
native binary and made available at runtime.

Fwiw, the output of Quarkus is a single runnable jar, so everything is
flattened.  For embedded dependencies, this may require additional work,
but nothing impossible. Problems may come when using the OSGi registry and
for class visibility.  The fact that the OSGi framework would work in a
single classloader may cause some problems with bundles wrt service and
classes visibility, because there would be no hidden classes anymore,
everything would be visible to all bundles.  The other problem would
definitely be for native mode (reflection and a few other limitations).
But a Quarkus JVM mode could definitely be interesting to have for  Karaf
static distributions.

Even with a few limitations, like forcing the user to align dependencies to
avoid multiple versions of the same class which would remove the need for a
complex shading mechanism, it could be worth investigating the benefit when
booting those karaf static distributions.  I think it could be a big win
for Karaf users.

Le ven. 11 oct. 2019 à 09:07, Christian Schneider <ch...@die-schneider.net>
a écrit :

> There is also another issue about embedding dependencies.
>
> In OSGi it is quite popular to embed dependencies into the bundle with the
> original package names.
> When used in a flat classloader this makes these embedded packages collide
> between bundles. This can be solved though by embedding with a different
> unique
> classname. I think the shade plugin can do this but I have never tried.
>
> Christian
>
> Am Fr., 11. Okt. 2019 um 08:52 Uhr schrieb Guillaume Nodet <
> gno...@apache.org>:
>
> > Le ven. 11 oct. 2019 à 08:37, Jean-Baptiste Onofré <j...@nanthrax.net> a
> > écrit :
> >
> > > Just a side note, not necessary about "happens during runtime" ;)
> > >
> > > Look on the Karaf static distribution:
> > >
> > >
> > >
> >
> https://github.com/apache/karaf/tree/master/examples/karaf-docker-example/karaf-docker-example-static-dist
> > >
> > > you will see that the resolution is "prepared" at build time, the
> > > runtime resolution is super fast.
> > >
> > > Karaf is not necessary "I start empty and I add stuff in it", it can be
> > > "I prepare all at build for a super fast start".
> > >
> >
> > That's right, but Quarkus goes a lot further than what Karaf does (which
> is
> > to basically to pre-install the bundles).
> > Such Karaf distributions could eventually benefit from Quarkus too, but
> > going native Karaf still uses OSGi and dynamic classloading, whereas
> > compiling to native imposes the whole world to be know at build time and
> > thus prohibits the use of dynamic classloading.
> > So I think there would be a path for Karaf to leverage Quarkus but that
> > would be very limited in JVM mode, unless Karaf is only used to create a
> > Quarkus powered distribution where the OSGi classloading would go away.
> In
> > a karaf "static" distribution, we could actually think about it, i.e. use
> > something like Felix Connect instead of a real Felix / Equinox framework,
> > which removes all classloaders afaik.  The only limitation would be to
> > choose a way to handle multiple bundle versions, either by rejecting
> those
> > use cases, or try to shadow them into a different package.
> >
> >
> > >
> > > Regards
> > > JB
> > >
> > > On 11/10/2019 08:17, Patrique Legault wrote:
> > > > Thank you for your response.
> > > >
> > > > That is very interesting to know. I did not know that Quarkus can do
> > all
> > > of
> > > > that rendering in build time. It makes sense that this is the
> opposite
> > of
> > > > OSGi as everythin happens during runtime.
> > > >
> > > > Thank you.
> > > >
> > > > On Fri., Oct. 11, 2019, 6:56 a.m. Grzegorz Grzybek, <
> > > gr.grzy...@gmail.com>
> > > > wrote:
> > > >
> > > >> Hello
> > > >>
> > > >> I'm not expert on Quarkus (and GraalVM)... Quoting one of the
> > > descriptions:
> > > >>
> > > >> *The approach that Quarkus takes is to tailor a runtime that only
> > > contains
> > > >>> what your application needs and to boil down most of the dynamics
> of
> > an
> > > >>> enterprise runtime.*
> > > >>>
> > > >>
> > > >> The idea is to get rid of all the parts of the Java runtime aspects
> > that
> > > >> ... do nothing except preparing your application to run. These are:
> > > >>  – initialization of jaxb context
> > > >>  – configuring Hibernate model
> > > >>  – wiring your CDI beans
> > > >>  – wiring your Spring beans
> > > >>  – generally transforming some metadata (annotations, XMLs,
> > > configurations,
> > > >> ...) into a live object model that no longer changes (usually
> > hashmaps)
> > > >>
> > > >> When the model is read, application does it's job. And we all
> confirm,
> > > that
> > > >> if the only goal of Java application is to read file and store it
> into
> > > >> database, starting Hibernate sessionfactory → session and creating
> > Camel
> > > >> context to do that is ~95% of entire work. Rest is "read file, store
> > in
> > > >> DB".
> > > >>
> > > >> Quarkus' goal is to move this 95% work to build time. Yes - build
> > time.
> > > >> Effectively the goal is to have Java application, that (when
> starting)
> > > >> *already has this model read* - and (in extreme) just mapped in your
> > > >> process' virtual memory as set of pages that JVM can already use.
> > > >> And it's not only making native JVM images.
> > > >>
> > > >> This is *directly* opposite to what Karaf (and OSGi in general) is
> > for.
> > > >>
> > > >> But maybe +Guillaume Nodet <gno...@apache.org> can tell more about
> it
> > > ;)
> > > >>
> > > >> regards
> > > >> Grzegorz Grzybek
> > > >>
> > > >> czw., 10 paź 2019 o 23:48 Patrique Legault <
> patriquelega...@gmail.com
> > >
> > > >> napisał(a):
> > > >>
> > > >>> Yes exactly what I meant.
> > > >>>
> > > >>> On Thu., Oct. 10, 2019, 11:39 p.m. Krzysztof Sobkowiak, <
> > > >>> krzys.sobkow...@gmail.com> wrote:
> > > >>>
> > > >>>> Hi
> > > >>>>
> > > >>>> Do you mean a Karaf feature prviding the Quarkus libraries (like
> the
> > > >>>> Spring or Hibernate feaures)?
> > > >>>>
> > > >>>> Best regards
> > > >>>> Krzysztof
> > > >>>>
> > > >>>> On Thu, 2019-09-26 at 15:25 -0400, Patrique Legault wrote:
> > > >>>>> Hello Romain,
> > > >>>>>
> > > >>>>> Let me just start by saying I probably should have done more
> > research
> > > >>> on
> > > >>>>> Quarkus before sending off this email.
> > > >>>>>
> > > >>>>> In my mind when I think of Karaf, I think of a service that
> allows
> > > >>>>> developers to simply install a feature into the service and gives
> > > >> them
> > > >>>>> access to a framework that they can then develop against. For
> > > >> instance,
> > > >>>>> installing a version of hibernate, spring, etc...into the Karaf
> > > >>> service.
> > > >>>>>
> > > >>>>> When I saw the Quarkus framework, I thought of a potential
> > > >> opportunity
> > > >>>> for
> > > >>>>> Karaf to provide another framework for developers to use. That
> > being
> > > >>> said
> > > >>>>> if this is something that Karaf already exposes through various
> > other
> > > >>>>> libraries then there is nothing to do.
> > > >>>>>
> > > >>>>> Next time though I will definitely do some more research prior
> to a
> > > >>>>> proposition.
> > > >>>>>
> > > >>>>> Cheers,
> > > >>>>>
> > > >>>>> On Thu, Sep 26, 2019 at 10:10 AM Jamie G. <
> > jamie.goody...@gmail.com>
> > > >>>> wrote:
> > > >>>>>
> > > >>>>>> I'm not sure the the ask entails here.
> > > >>>>>>
> > > >>>>>> Why does it need to be integrated into Karaf? Can Quarkus just
> > > >>> publish
> > > >>>>>> a feature which Karaf users could install in the usual manner?
> > > >>>>>>
> > > >>>>>> On Thu, Sep 26, 2019 at 11:34 AM Romain Manni-Bucau
> > > >>>>>> <rmannibu...@gmail.com> wrote:
> > > >>>>>>> Hi Patrique,
> > > >>>>>>>
> > > >>>>>>> I have to admit I'm not following, Quarkus is mainly a
> > > >> microprofile
> > > >>>> based
> > > >>>>>>> server integrated with GraalVM in the IBM/Redhat ecosystem to
> > > >> build
> > > >>>>>>> natively a HTTP app (for k8s).
> > > >>>>>>> It also supports a JVM mode but then it is like any CDI/JAXRS
> > > >>> server.
> > > >>>>>>> In this last mode Karaf is already very competitive so I guess
> it
> > > >>> is
> > > >>>> not
> > > >>>>>>> the target and in the first mode the current challenge of Graal
> > > >> for
> > > >>>> Karaf
> > > >>>>>>> (OSGi actually) is that it does not support classloading (and
> > > >>>> conflicting
> > > >>>>>>> API in the same application).
> > > >>>>>>>
> > > >>>>>>> Concretely my point is that Karaf already supports Tomcat and
> > > >> Jetty
> > > >>>> (and
> > > >>>>>>> undertow i think) through pax-web and jersey/cxf so it already
> > > >> has
> > > >>> a
> > > >>>>>> "lean
> > > >>>>>>> and efficient Java server". Add all the recent work about
> > > >>>>>> containerization
> > > >>>>>>> (static resolver, docker mojo etc) and you can couple it with
> > > >>>> "container
> > > >>>>>>> first framework".
> > > >>>>>>>
> > > >>>>>>> Finally, still relying on the JVM enable to Karaf to be more
> > > >>>> reliable at
> > > >>>>>>> runtime that Quarkus in native mode which still has a poor GC
> > > >>>>>>> implementation (it will be enhanced but they are not yet
> there).
> > > >>>>>>>
> > > >>>>>>> All that to say I'm not sure the outcome you expect of such a
> > > >> task,
> > > >>>> can
> > > >>>>>> you
> > > >>>>>>> refine it a bit maybe?
> > > >>>>>>>
> > > >>>>>>> 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 jeu. 26 sept. 2019 à 15:54, Patrique Legault <
> > > >>>>>> patriquelega...@gmail.com>
> > > >>>>>>> a écrit :
> > > >>>>>>>
> > > >>>>>>>> There is a new framework released by Red Hat called Quarkus,
> > > >> see
> > > >>>>>>>> https://quarkus.io/, it is designed/built for
> > > >> containerization .
> > > >>>>>>>>
> > > >>>>>>>> If integrated within Karaf, we could create a feature that
> > > >> would
> > > >>>>>> install
> > > >>>>>>>> the Quarkus framework within Karaf. This would allow for a
> lean
> > > >>> and
> > > >>>>>>>> efficient Java server with a container first framework
> embedded
> > > >>>> within
> > > >>>>>> it.
> > > >>>>>>>> Allowing for quick and easy RESTful services development with
> a
> > > >>> low
> > > >>>>>> memory
> > > >>>>>>>> footprint and quick container runtime.
> > > >>>>>>>>
> > > >>>>>>>> Let me know what you think, and if this is worth logging a
> > > >> ticket
> > > >>>> for.
> > > >>>>>>>>
> > > >>>>>>>> Cheers,
> > > >>>>>>>>
> > > >>>>>>>> --
> > > >>>>>>>> *Patrique Legault*
> > > >>>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>> --
> > > >>>> Krzysztof Sobkowiak
> > > >>>>
> > > >>>> JEE & OSS Architect, Integration Architect
> > > >>>> Apache Software Foundation Member (http://apache.org/)
> > > >>>> Apache ServiceMix Committer & PMC Member (
> > > >> http://servicemix.apache.org/)
> > > >>>> Apache OpenWhisk PMC Member (https://openwhisk.apache.org/)
> > > >>>> Apache Incubator PMC Member (https://incubator.apache.org/)
> > > >>>> Senior Solution Architect @ Capgemini SSC (
> > > >>>> http://www.capgeminisoftware.pl/)
> > > >>>>
> > > >>>>
> > > >>>
> > > >>
> > > >
> > >
> > > --
> > > Jean-Baptiste Onofré
> > > jbono...@apache.org
> > > http://blog.nanthrax.net
> > > Talend - http://www.talend.com
> > >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> >
>
>
> --
> --
> Christian Schneider
> http://www.liquid-reality.de
>
> Computer Scientist
> http://www.adobe.com
>


-- 
------------------------
Guillaume Nodet

Reply via email to