Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau <[email protected]> a écrit :
> > > 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. > Ok. What do you have in mind exactly ? At first glance, it seems you want to scan and register all classes for reflection and all resources to be included ? If that's what you have mind, I think it can cause some problems: the graal vm heavily rely on dead code elimination (because the world is known and it can analyse all the code paths). I fear that registering all classes for full reflection may have a very bad effect of actually killing any dead code elimination, because all methods / classes will have to be present in the compiled code. Subsequent effects will be a bigger native code size and longer native code compilation... Or do you have something smarter in mind ? > > > >> >>> >>> 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 >> >> -- ------------------------ Guillaume Nodet
