Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau <rmannibu...@gmail.com> a écrit :
> > > Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gno...@apache.org> a > écrit : > >> >> >> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <rmannibu...@gmail.com> >> a écrit : >> >>> Hi Raymond, >>> >>> What do you mean y "taking us down"? >>> To give some background, I have some use case where a k8s orchestrator + >>> native java run would be a good option compared to a long running program >>> (see it as lambda like archi). >>> I did some basic tooling - guess it is the same than you more or less - >>> and just would like a home for now. >>> Now I agree graal is not for all apps, it is not even possible to >>> compile a jdbc driver today - yes quarkus faked it ;). >>> >> >> I've been working on camel-quarkus recently and we do have integration >> tests that use JDBC and that are compiled to native mode. >> Not sure what you mean when you say it's not possible to compile a jdbc >> driver. I'd be interested in understanding what you mean here. >> > > It is going a bit off topic and guess if arthur has no strong objection > we'll discuss it a bit in other threads but long story short,if you dont > replace a bunch of code the driver will not work. Quarkus h2 kept only > client mode to simplify part of it. H2 by itself works in client, file and > mem if you do the reflection work but then if the jdbc pool or app uses > DriverManager, most codepath will require to load all the driver at build > time and often end up on some blocker you need to cut like natives or > unsupported api. I got the same experience with derby. It is not the driver > by itself but the SPI + common driver/jdbc usages which make it often hard > to use without forking part of the libs. > Fun fact is hikari is broken by that but not tomcat-jdbc cause their > load(driver)/DriverManager chain is opposed. > That's nothing related to Quarkus but just the effect of native code compilation I think. The limitation comes from compiling to native: the whole world has to be known at compile time, so dynamic class loading is not feasible. Loading a "new" jdbc driver dynamically will never work in native mode. However, the SPIs (be it xml, jaxb, jdbc or whatever) usually rely on loading a properties file and instantiating the class name found in it. This part can be made to work in native mode, but it has to be known at build time and taken care of. In this case, one needs to instruct the native compiler about the properties file (so that it's included in the native binary) and about the reflection needed for the driver class (so that it can be instantiated using its class name). So the short answer is : if you try to take any complex application and compile it to native mode, it won't work as is. And that's the reason why all libraries need to be "validated" before being usable in a native compilation : each limitation of the graal vm needs to be worked around, things explicited, reflection known before hand, etc... Quarkus, amongst other things, helps doing that and provides a set of "validated" components. > > Romain > > > >> Guillaume >> >> >>> >>> 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 ven. 25 oct. 2019 à 16:02, Raymond Auge <raymond.a...@liferay.com> a >>> écrit : >>> >>>> I'm not vehemently opposed as I have done my own graal salivating and >>>> not that I think anyone would care much even if I was completely opposed; >>>> but I will caution that this whole graal thing is a dangerous path that >>>> Oracle (and seemingly Redhat is just as happy to do it) are taking us all >>>> down. >>>> >>>> Anyway +0.5 >>>> >>>> Sincerely, >>>> - Ray >>>> >>>> On Fri, Oct 25, 2019 at 2:21 PM Francois Papon < >>>> francois.pa...@openobject.fr> wrote: >>>> >>>>> Hi Romain! >>>>> >>>>> I think it's a great idea, it make sense to have tooling around >>>>> graalvm. >>>>> >>>>> I will be more than happy to contribute ;) >>>>> >>>>> "arthur" looks good to me :) >>>>> >>>>> regards, >>>>> >>>>> Françoisfpa...@apache.org >>>>> >>>>> Le 25/10/2019 à 09:00, Romain Manni-Bucau a écrit : >>>>> >>>>> Hi everyone, >>>>> >>>>> Wonder if we want to create a small project to simplify graalvm builds? >>>>> What I have in mind is basically a kind of main (+ maven wrapper) >>>>> which enables to use scanning at build time to prepare a binary, do the >>>>> right RuntimeReflection.register and set the right configuration for >>>>> proxies, resources etc. >>>>> It would be a companion of XBean finder - which is a perfect fit for >>>>> this phase - but likely outside of XBean since the project will likely >>>>> require to use docker for tests - since we go native, otherwise we >>>>> wouldn't >>>>> build portably - and creates its own ecosystem. >>>>> >>>>> Side note: if we go with it, I'm tempted to call it "arthur", if you >>>>> +1 the idea don't hesitate to also comment on the name >>>>> >>>>> 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> >>>>> >>>>> >>>> >>>> -- >>>> *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> >>>> (@rotty3000) >>>> Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> >>>> (@Liferay) >>>> >>> >> >> -- >> ------------------------ >> Guillaume Nodet >> >> -- ------------------------ Guillaume Nodet
