Nice! Thanks Romain!
regards, François fpa...@apache.org Le 29/10/2019 à 08:52, Romain Manni-Bucau a écrit : > Hi everyone, > > Just created the repository as mentionned earlier. > > Here it is: https://gitbox.apache.org/repos/asf?p=geronimo-arthur.git > > I will try to add some basic doc module and work on tests after. > > 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 lun. 28 oct. 2019 à 18:47, Jean-Baptiste Onofré <j...@nanthrax.net > <mailto:j...@nanthrax.net>> a écrit : > > It sounds good. +1. > > Regards > JB > > On 28/10/2019 18:07, Romain Manni-Bucau wrote: >> 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 >> <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>> 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 >> <gno...@apache.org <mailto:gno...@apache.org>> a écrit : >> >> >> >> Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau >> <rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>> a >> écrit : >> >> >> >> Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet >> <gno...@apache.org <mailto:gno...@apache.org>> a écrit : >> >> >> >> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau >> <rmannibu...@gmail.com >> <mailto:rmannibu...@gmail.com>> a écrit : >> >> >> >> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet >> <gno...@apache.org >> <mailto:gno...@apache.org>> a écrit : >> >> >> >> Le ven. 25 oct. 2019 à 16:28, Romain >> Manni-Bucau <rmannibu...@gmail.com >> <mailto: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. >> >> >> 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 <raymond.a...@liferay.com >> <mailto: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 >> <mailto: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çois >> fpa...@apache.org >> <mailto:fpa...@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 >> >> >> >> -- >> ------------------------ >> Guillaume Nodet >>
