In my case, substratevm itself pointed to me which class was being reflected
on. Though it didn't specify which fields or methods, but I just set it to
allow all methods and fields of the reported classes to be allowed.
--
You received this message because you are subscribed to the Google
Thank you Didier, I've seen this documentation about the reflection json
file. However it appears that even `(set! *warn-on-reflections true)`
doesn't always catch reflections. I suppose it means I have to use
profilers like jvisualvm (don't remember the exact name) to watch for calls
to
You can give substratevm a reflection json file though. That did the trick for
me.
https://github.com/oracle/graal/blob/master/substratevm/REFLECTION.md
So you just need to tell it in advance what class you will reflect on and how.
Then it should work.
--
You received this message because
Hum, I hadn't heard of jaotc. Hopefully it will continue to be developed. A
slower Clojure which starts mich faster yet is fully compatible would be a nice
trade off in many cases.
I found this reading interesting:
https://mjg123.github.io/2017/10/04/AppCDS-and-Clojure.html#using-cds
For
Thanks a lot for the links. Indeed it seems that parts of Clojure inevitably
end up using reflections unless anotated.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from
Hi Khalid,
Reflections [1] are a big problem too for Graalvm. Here is a thread of
playing with Clojure and Graalvm [2]. If you follow the links, you will see
some issues I ran into.
Hth,
Jeroen
[1] Ones that are and aren't caught by *warn-on-reflections*
It's already possibly, but not really part of, that would make little sense
anyway. It shines with tools you want to run quickly, where the reduction in
startup time helps. There was a tweet if a formatter compiled to a native image.
I also tried to create a native image for a pretty project,
Thanks for pointing out jaotc. It's not what I need but it's good to know
it exists. Do you know if it's possible to AOT (part of) a Clojure program
with it? I'm curious.
On Mon, Nov 26, 2018, 7:06 PM Ghadi Shayban Substrate makes a closed world assumption. jaotc is open world, and also
> based
Substrate makes a closed world assumption. jaotc is open world, and also based
on Graal.
--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clojure@googlegroups.com
Note that posts from new members are moderated -
Thanks a lot. So it means Clojure's `eval` is by design incompatible with
SubstrateVM.
Does anyone know of others hard incompatibilities ?
On Monday, November 26, 2018 at 6:16:20 PM UTC+1, Gary Trakhman wrote:
>
> Yes, eval will generate classes in a dynamic classloader, load them, then
> call
Yes, eval will generate classes in a dynamic classloader, load them, then
call methods on the newly formed class/object except for
too-simple-to-be-interesting cases.
On Mon, Nov 26, 2018 at 11:43 AM Khalid Jebbari
wrote:
> Hi,
>
> I was doing a small experiment with Clojure and GraalVM and
Hi,
I was doing a small experiment with Clojure and GraalVM and ended with this
minimal reproduction case of an incompatibility between Clojure's `eval`
and GraalVM's native-image tool (the program that compiles a JVM program to
a native executable, based on the GraalVM's SubstrateVM
12 matches
Mail list logo
