It sounds good. +1.
Regards
JB
On 28/10/2019 18:07, Romain Manni-Bucau wrote:
Hi everyone,
I'm planning to create the repo tomorrow and try to get some doc for
wednesday night.
Is it ok for everyone?
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le dim. 27 oct. 2019 à 18:04, Romain Manni-Bucau
<rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>> a écrit :
Hi Guillaume,
Yes and no, First iteration I'd like to:
1. Enable to build a command graal line and execute it through a
mojo (to have an e2e case)
2. Provide a simple API to let the user register classes (my
current version is very specific to a few frameworks so i must
abstract it but idea is to let some classes be found based on
annotations or parent for ex and register them). Guess it will not
use a feature but more a preprocessing phase generating a valid
reflection.json (potentially resources.json and dynamicproxy.json
in terms of design). Then we can run 1. with this config. In my
case - job framework - i can find all the classes i need
reflection on so i just list them all (it is close to Arc I guess?).
3. (optional for first import) provide some library integrations
(substitutions and/or features, no arthur abstraction) to help
with some common libraries. I needed some for johnzon so it can be
one integration module for ex.
Hope it makes sense.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github
<https://github.com/rmannibucau> | LinkedIn
<https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le dim. 27 oct. 2019 à 17:37, Guillaume Nodet <gno...@apache.org
<mailto:gno...@apache.org>> a écrit :
Le sam. 26 oct. 2019 à 08:11, Romain Manni-Bucau
<rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>> a écrit :
Le sam. 26 oct. 2019 à 00:22, Guillaume Nodet
<gno...@apache.org <mailto:gno...@apache.org>> a écrit :
Le ven. 25 oct. 2019 à 22:42, Romain Manni-Bucau
<rmannibu...@gmail.com <mailto:rmannibu...@gmail.com>>
a écrit :
Le ven. 25 oct. 2019 à 21:34, Guillaume Nodet
<gno...@apache.org <mailto:gno...@apache.org>> a
écrit :
Le ven. 25 oct. 2019 à 16:28, Romain
Manni-Bucau <rmannibu...@gmail.com
<mailto:rmannibu...@gmail.com>> a écrit :
Hi Raymond,
What do you mean y "taking us down"?
To give some background, I have some use
case where a k8s orchestrator + native
java run would be a good option compared
to a long running program (see it as
lambda like archi).
I did some basic tooling - guess it is the
same than you more or less - and just
would like a home for now.
Now I agree graal is not for all apps, it
is not even possible to compile a jdbc
driver today - yes quarkus faked it ;).
I've been working on camel-quarkus recently
and we do have integration tests that use JDBC
and that are compiled to native mode.
Not sure what you mean when you say it's not
possible to compile a jdbc driver. I'd be
interested in understanding what you mean here.
It is going a bit off topic and guess if arthur
has no strong objection we'll discuss it a bit in
other threads but long story short,if you dont
replace a bunch of code the driver will not work.
Quarkus h2 kept only client mode to simplify part
of it. H2 by itself works in client, file and mem
if you do the reflection work but then if the jdbc
pool or app uses DriverManager, most codepath will
require to load all the driver at build time and
often end up on some blocker you need to cut like
natives or unsupported api. I got the same
experience with derby. It is not the driver by
itself but the SPI + common driver/jdbc usages
which make it often hard to use without forking
part of the libs.
Fun fact is hikari is broken by that but not
tomcat-jdbc cause their load(driver)/DriverManager
chain is opposed.
That's nothing related to Quarkus but just the effect
of native code compilation I think.
The limitation comes from compiling to native: the
whole world has to be known at compile time, so
dynamic class loading is not feasible. Loading a "new"
jdbc driver dynamically will never work in native
mode. However, the SPIs (be it xml, jaxb, jdbc or
whatever) usually rely on loading a properties file
and instantiating the class name found in it. This
part can be made to work in native mode, but it has to
be known at build time and taken care of. In this
case, one needs to instruct the native compiler about
the properties file (so that it's included in the
native binary) and about the reflection needed for the
driver class (so that it can be instantiated using its
class name).
So the short answer is : if you try to take any
complex application and compile it to native mode, it
won't work as is. And that's the reason why all
libraries need to be "validated" before being usable
in a native compilation : each limitation of the graal
vm needs to be worked around, things explicited,
reflection known before hand, etc... Quarkus, amongst
other things, helps doing that and provides a set of
"validated" components.
I didnt say quarkus was guilty, point was that even the
very high investment ibm/redhat did, h2 is not supported
by their stack except in client mode which is not a
simplicity sign. Sorry if it was ambiguous, my point was
not to blame but to highlight I agreee with Ray we must
not emphasis the simplicity of graal but only enable the
build to be less hard.
Ok.
What do you have in mind exactly ? At first glance, it seems
you want to scan and register all classes for reflection and
all resources to be included ?
If that's what you have mind, I think it can cause some
problems: the graal vm heavily rely on dead code elimination
(because the world is known and it can analyse all the code
paths). I fear that registering all classes for full
reflection may have a very bad effect of actually killing any
dead code elimination, because all methods / classes will have
to be present in the compiled code. Subsequent effects will
be a bigger native code size and longer native code compilation...
Or do you have something smarter in mind ?
Romain
Guillaume
Romain Manni-Bucau
@rmannibucau
<https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old
Blog <http://rmannibucau.wordpress.com> |
Github <https://github.com/rmannibucau> |
LinkedIn
<https://www.linkedin.com/in/rmannibucau> |
Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le ven. 25 oct. 2019 à 16:02, Raymond Auge
<raymond.a...@liferay.com
<mailto:raymond.a...@liferay.com>> a écrit :
I'm not vehemently opposed as I have
done my own graal salivating and not
that I think anyone would care much
even if I was completely opposed; but
I will caution that this whole graal
thing is a dangerous path that Oracle
(and seemingly Redhat is just as happy
to do it) are taking us all down.
Anyway +0.5
Sincerely,
- Ray
On Fri, Oct 25, 2019 at 2:21 PM
Francois Papon
<francois.pa...@openobject.fr
<mailto:francois.pa...@openobject.fr>>
wrote:
Hi Romain!
I think it's a great idea, it make
sense to have tooling around graalvm.
I will be more than happy to
contribute ;)
"arthur" looks good to me :)
regards,
François
fpa...@apache.org
<mailto:fpa...@apache.org>
Le 25/10/2019 à 09:00, Romain
Manni-Bucau a écrit :
Hi everyone,
Wonder if we want to create a
small project to simplify graalvm
builds?
What I have in mind is basically
a kind of main (+ maven wrapper)
which enables to use scanning at
build time to prepare a binary,
do the right
RuntimeReflection.register and
set the right configuration for
proxies, resources etc.
It would be a companion of XBean
finder - which is a perfect fit
for this phase - but likely
outside of XBean since the
project will likely require to
use docker for tests - since we
go native, otherwise we wouldn't
build portably - and creates its
own ecosystem.
Side note: if we go with it, I'm
tempted to call it "arthur", if
you +1 the idea don't hesitate to
also comment on the name
Romain Manni-Bucau
@rmannibucau
<https://twitter.com/rmannibucau>
| Blog
<https://rmannibucau.metawerx.net/> |
Old Blog
<http://rmannibucau.wordpress.com>
| Github
<https://github.com/rmannibucau> |
LinkedIn
<https://www.linkedin.com/in/rmannibucau> |
Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
--
*Raymond Augé*
<http://www.liferay.com/web/raymond.auge/profile> (@rotty3000)
Senior Software Architect *Liferay,
Inc.* <http://www.liferay.com> (@Liferay)
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
--
------------------------
Guillaume Nodet
