This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-07-28
Channels
- # asami (1)
- # aws (9)
- # babashka (16)
- # beginners (32)
- # calva (2)
- # clj-kondo (20)
- # cljdoc (6)
- # clojure (35)
- # clojure-dev (25)
- # clojure-europe (11)
- # clojure-india (1)
- # clojure-norway (2)
- # clojure-spec (26)
- # clojure-uk (1)
- # clojurescript (41)
- # conjure (3)
- # css (9)
- # cursive (18)
- # data-oriented-programming (6)
- # data-science (2)
- # emacs (47)
- # events (1)
- # fulcro (15)
- # graalvm (30)
- # gratitude (7)
- # honeysql (27)
- # inf-clojure (4)
- # introduce-yourself (2)
- # lsp (129)
- # malli (7)
- # missionary (21)
- # nbb (17)
- # off-topic (18)
- # re-frame (6)
- # releases (1)
- # shadow-cljs (120)
- # vim (7)
- # xtdb (15)
How can I start compiling my JAR into GraalVM? I added :gen-class
and wrapped my SecureRandom
in delay
but then I have to make the logger work and I use [com.fzakaria/slf4j-timbre "0.3.21"]
+`[org.clojure/tools.logging "1.2.4"]` which isn't liked by the native-image
compiler. So... should I change my logger or what? I think that it does some logging even during compilation time and it gets initialized so I'm not sure what to do.
Maybe my logging is misconfigured?
This is the error from GraalVM:
Caused by: com.oracle.graal.pointsto.constraints.UnsupportedFeatureException: No instances of com.github.fzakaria.slf4j.timbre.TimbreLoggerAdapter are allowed in the image heap as this class should be initialized at image runtime. Object has been initialized by the io.netty.channel.nio.AbstractNioChannel class initializer with a trace:
`
I don't understand why that is a problem :thinking_face:
This is my command:
native-image -jar ./target/uberjar/app.jar --initialize-at-run-time=com.github.fzakaria.slf4j.timbre.TimbreLoggerAdapter --trace-object-instantiation=com.github.fzakaria.slf4j.timbre.TimbreLoggerAdapter
@invertisment_clojuria If you see logging during compilation this means you have an expression like this:
(def foo (do (+ 1 2 3) (log "hello")))
either directly or via a function call on the top level.But this is inside of a method fn. So it can be dynamic :thinking_face: Isn't it?
Or does that mean that graalvm will load the log
function and inline it in nasty ways and that's why it puts it onto the heap?
Something triggers the log once during the build of uberjar (I think something loads netty and it logs one line).
But almost all my functions that do logging are declared in top-level. So then do I need to make a workaround in native-image
command?
> Something triggers the log once during the build of uberjar Yes so this is why it happens during compilation of native image as well
It's not about functions, it's about something that calls this function on the top level
Alright. I think it's some kind of a library that does this. I'll try to find out. This is the line that appears when I build uberjar.
22-07-28 08:06:03 _ INFO [org.eclipse.jetty.util.log:170] - Logging initialized @15374ms to org.eclipse.jetty.util.log.Slf4jLog
Found the culprit: https://github.com/eclipse/jetty.project/blob/cb127793e5d8b5c5730b964392a9a905ba49191d/jetty-util/src/main/java/org/eclipse/jetty/util/ssl/KeyStoreScanner.java#L39 It's imported when jetty is imported. So the log message is triggered on the import.
https://github.com/ring-clojure/ring/commit/cb28ec5a0897f67cd653657141b752a52f19e0fd
Is anyone using byte-streams with Graal? I could use a hand if so.
We deprecated the top-level byte-streams
ns and copied everything lower down to clj-commons.byte-streams
. Well, we just got a bug report related to an update that changed the lower ns but not the top-level ns. Rather than copy changes back for the indefinite future, and testing both, I’m considering using potemkin to import all the vars to the old ns, so they’re always in sync.
The primary reason we deprecated the top-level ns was because it caused graal problems (clj-easy/graal problems, in particular). In theory, graal users requiring the clj-commons.byte-streams ns should be insulated from top-level ns changes. However, I don’t use Graal, and potemkin can do some weird things, so I was hoping to find someone to test it when ready, just to make sure.
I'm aware of that top level ns move, I was one of the people who proposed that. If you use potemkin only in the top level ns, the nested ns won't have any problems with that
Because I got a bug report over it 😄
but in response to the bug report, why not tell people: migrate to the nested ns first and we'll fix it there?
It was kind of indirect, since the issue cropped up in some Aleph example code
So it was a valid thing we needed to fix, but I figured, why not prevent this from ever being an issue?
True, true. I just don’t want to waste time on it, or cause users problems, if potemkin/import-vars can fix it all…of course potemkin is also a top-level ns, so that might require changes for graal as well. ¯\(ツ)/¯
My stance is: don't waste any energy on the deprecated ns and tell people to migrate, change the examples :)
Fair. Maybe it won’t be a big issue.