This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # 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
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:
` I don't understand why that is a problem :thinking_face: This is my command:
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:
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:
either directly or via a function call on the top level.
(def foo (do (+ 1 2 3) (log "hello")))
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
> 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.
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
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 :)