Hi Guillaume, Yes and no, First iteration I'd like to:
1. Enable to build a command graal line and execute it through a mojo (to have an e2e case) 2. Provide a simple API to let the user register classes (my current version is very specific to a few frameworks so i must abstract it but idea is to let some classes be found based on annotations or parent for ex and register them). Guess it will not use a feature but more a preprocessing phase generating a valid reflection.json (potentially resources.json and dynamicproxy.json in terms of design). Then we can run 1. with this config. In my case - job framework - i can find all the classes i need reflection on so i just list them all (it is close to Arc I guess?). 3. (optional for first import) provide some library integrations (substitutions and/or features, no arthur abstraction) to help with some common libraries. I needed some for johnzon so it can be one integration module for ex. Hope it makes sense. 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 dim. 27 oct. 2019 à 17:37, Guillaume Nodet <[email protected]> a écrit : > > > 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 > >
