You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2019/10/25 07:00:28 UTC
[DISCUSS] graal tooling?
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>
Re: [DISCUSS] graal tooling?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
Hi
It sounds good to me ! Good idea.
Regards
JB
On 25/10/2019 09:00, Romain Manni-Bucau wrote:
> 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>
Re: [DISCUSS] graal tooling?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Hello everyone,
I pushed a first version online:
https://geronimo.apache.org/arthur/index.html. The most interesting one is
likely the maven one today: https://geronimo.apache.org/arthur/maven.html.
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 mar. 29 oct. 2019 à 10:02, Francois Papon <fr...@openobject.fr>
a écrit :
> Nice!
>
> Thanks Romain!
>
> regards,
>
> Françoisfpapon@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é <jb...@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 <rm...@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 <gn...@apache.org> a
>>> écrit :
>>>
>>>>
>>>>
>>>> Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau <rm...@gmail.com>
>>>> a écrit :
>>>>
>>>>>
>>>>>
>>>>> Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet <gn...@apache.org> a
>>>>> écrit :
>>>>>
>>>>>>
>>>>>>
>>>>>> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau <
>>>>>> rmannibucau@gmail.com> a écrit :
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gn...@apache.org> a
>>>>>>> écrit :
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <
>>>>>>>> rmannibucau@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.auge@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.papon@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çoisfpapon@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
>>>>
>>>>
Re: [DISCUSS] graal tooling?
Posted by Francois Papon <fr...@openobject.fr>.
Nice!
Thanks Romain!
regards,
François
fpapon@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é <jb@nanthrax.net
> <ma...@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
>> <rmannibucau@gmail.com <ma...@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
>> <gnodet@apache.org <ma...@apache.org>> a écrit :
>>
>>
>>
>> Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau
>> <rmannibucau@gmail.com <ma...@gmail.com>> a
>> écrit :
>>
>>
>>
>> Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet
>> <gnodet@apache.org <ma...@apache.org>> a écrit :
>>
>>
>>
>> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau
>> <rmannibucau@gmail.com
>> <ma...@gmail.com>> a écrit :
>>
>>
>>
>> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet
>> <gnodet@apache.org
>> <ma...@apache.org>> a écrit :
>>
>>
>>
>> Le ven. 25 oct. 2019 à 16:28, Romain
>> Manni-Bucau <rmannibucau@gmail.com
>> <ma...@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.auge@liferay.com
>> <ma...@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.papon@openobject.fr
>> <ma...@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
>> fpapon@apache.org <ma...@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
>>
Re: [DISCUSS] graal tooling?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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é <jb...@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 <rm...@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 <gn...@apache.org> a
>> écrit :
>>
>>>
>>>
>>> Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau <rm...@gmail.com>
>>> a écrit :
>>>
>>>>
>>>>
>>>> Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet <gn...@apache.org> a
>>>> écrit :
>>>>
>>>>>
>>>>>
>>>>> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau <
>>>>> rmannibucau@gmail.com> a écrit :
>>>>>
>>>>>>
>>>>>>
>>>>>> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gn...@apache.org> a
>>>>>> écrit :
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <
>>>>>>> rmannibucau@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.auge@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.papon@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çoisfpapon@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
>>>
>>>
Re: [DISCUSS] graal tooling?
Posted by Jean-Baptiste Onofré <jb...@nanthrax.net>.
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
> <rmannibucau@gmail.com <ma...@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 <gnodet@apache.org
> <ma...@apache.org>> a écrit :
>
>
>
> Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau
> <rmannibucau@gmail.com <ma...@gmail.com>> a écrit :
>
>
>
> Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet
> <gnodet@apache.org <ma...@apache.org>> a écrit :
>
>
>
> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau
> <rmannibucau@gmail.com <ma...@gmail.com>>
> a écrit :
>
>
>
> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet
> <gnodet@apache.org <ma...@apache.org>> a
> écrit :
>
>
>
> Le ven. 25 oct. 2019 à 16:28, Romain
> Manni-Bucau <rmannibucau@gmail.com
> <ma...@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.auge@liferay.com
> <ma...@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.papon@openobject.fr
> <ma...@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
> fpapon@apache.org <ma...@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
>
Re: [DISCUSS] graal tooling?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <rm...@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 <gn...@apache.org> a
> écrit :
>
>>
>>
>> Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau <rm...@gmail.com>
>> a écrit :
>>
>>>
>>>
>>> Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet <gn...@apache.org> a
>>> écrit :
>>>
>>>>
>>>>
>>>> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau <rm...@gmail.com>
>>>> a écrit :
>>>>
>>>>>
>>>>>
>>>>> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gn...@apache.org> a
>>>>> écrit :
>>>>>
>>>>>>
>>>>>>
>>>>>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <
>>>>>> rmannibucau@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 <ra...@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.papon@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çoisfpapon@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
>>
>>
Re: [DISCUSS] graal tooling?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <gn...@apache.org> a écrit :
>
>
> Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau <rm...@gmail.com>
> a écrit :
>
>>
>>
>> Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet <gn...@apache.org> a
>> écrit :
>>
>>>
>>>
>>> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau <rm...@gmail.com>
>>> a écrit :
>>>
>>>>
>>>>
>>>> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gn...@apache.org> a
>>>> écrit :
>>>>
>>>>>
>>>>>
>>>>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <
>>>>> rmannibucau@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 <ra...@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.papon@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çoisfpapon@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
>
>
Re: [DISCUSS] graal tooling?
Posted by Guillaume Nodet <gn...@apache.org>.
Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
>
>
> Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet <gn...@apache.org> a
> écrit :
>
>>
>>
>> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau <rm...@gmail.com>
>> a écrit :
>>
>>>
>>>
>>> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gn...@apache.org> a
>>> écrit :
>>>
>>>>
>>>>
>>>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <rm...@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 <ra...@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.papon@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çoisfpapon@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
Re: [DISCUSS] graal tooling?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet <gn...@apache.org> a écrit :
>
>
> Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau <rm...@gmail.com>
> a écrit :
>
>>
>>
>> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gn...@apache.org> a
>> écrit :
>>
>>>
>>>
>>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <rm...@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.
>
>>
>> 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 <ra...@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.papon@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çoisfpapon@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
>
>
Re: [DISCUSS] graal tooling?
Posted by Guillaume Nodet <gn...@apache.org>.
Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau <rm...@gmail.com> a
écrit :
>
>
> Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gn...@apache.org> a
> écrit :
>
>>
>>
>> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <rm...@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.
>
> 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 <ra...@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.papon@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çoisfpapon@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
Re: [DISCUSS] graal tooling?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet <gn...@apache.org> a écrit :
>
>
> Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <rm...@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.
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 <ra...@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.papon@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çoisfpapon@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
>
>
Re: [DISCUSS] graal tooling?
Posted by Guillaume Nodet <gn...@apache.org>.
Le ven. 25 oct. 2019 à 16:28, Romain Manni-Bucau <rm...@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.
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 <ra...@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.papon@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çoisfpapon@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
Re: [DISCUSS] graal tooling?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
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 <ra...@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.papon@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çoisfpapon@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)
>
Re: [DISCUSS] graal tooling?
Posted by Raymond Auge <ra...@liferay.com>.
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 <fr...@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çoisfpapon@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)
Re: [DISCUSS] graal tooling?
Posted by Francois Papon <fr...@openobject.fr>.
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
fpapon@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>