Fork me on GitHub
Martynas Maciulevičius07:07:52

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: 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 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.

Martynas Maciulevičius08:07:16

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?


this fn is then called on the top level


you don't see the logging if you compile your uberjar with clojure itself?


I would expect the same to happen

Martynas Maciulevičius08:07:43

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

Martynas Maciulevičius08:07:25

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

Matthew Davidson (kingmob)09:07:58

Is anyone using byte-streams with Graal? I could use a hand if so.


I don't think I do , but let me know your problems

Matthew Davidson (kingmob)09:07:41

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 why not just maintain the nested ns and tell people to migrate?


Imo the top level ns should not be edited anymore

Matthew Davidson (kingmob)09:07:17

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?

Matthew Davidson (kingmob)09:07:01

It was kind of indirect, since the issue cropped up in some Aleph example code


Update the example code too :)

Matthew Davidson (kingmob)09:07:47

So it was a valid thing we needed to fix, but I figured, why not prevent this from ever being an issue?


Because people should really be moving to the nested ns


and not fixing issues in the top level ns will encourage them to do so

Matthew Davidson (kingmob)09:07:27

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 :)

Matthew Davidson (kingmob)09:07:59

Fair. Maybe it won’t be a big issue.