Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet <[email protected]> a écrit :
> > > Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau <[email protected]> > a écrit : > >> >> >> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <[email protected]> a >> écrit : >> >>> >>> >>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <[email protected]> >>> 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. > I didnt say quarkus was guilty, point was that even the very high investment ibm/redhat did, h2 is not supported by their stack except in client mode which is not a simplicity sign. Sorry if it was ambiguous, my point was not to blame but to highlight I agreee with Ray we must not emphasis the simplicity of graal but only enable the build to be less hard. > >> >> 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 <[email protected]> >>>> 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 < >>>>> [email protected]> 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ç[email protected] >>>>>> >>>>>> 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 > >
