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. 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 > >
