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 ;).
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> 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> 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çoisfpa...@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) >
