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

no

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

I would expect the same to happen

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

https://github.com/ring-clojure/ring/issues/468

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

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

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

Update the example code too :)

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

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.