Hi everyone, I'm planning to create the repo tomorrow and try to get some doc for wednesday night. Is it ok for everyone?
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 à 18:04, Romain Manni-Bucau <[email protected]> a écrit : > 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 >> >>
