Fork me on GitHub

c/c @delaguardo about updating the actions :)


Should work just fine out of the box) but i will check later this evening. Thanks for the ping ūüėä


Amazing! Thanks!


Nice this is the first time the #babashka native image actually shrunk after upgrading. This is with Java 11. I expect a major Java upgrade will increase the size, but I will check.


@suskeyhose Perhaps one could try a native image with #coffi now that there is one for Java 17

Joshua Suskalo15:10:13

I can definitely give that a shot soon

Joshua Suskalo15:10:40

I have a basic program already written that should work assuming tools.logging is good with graal


tools.logging is just an abstract thing without an implementation


tools.logging is included in #babashka with timbre as the impl


so, as a data point, that happens to work

Karol Wójcik15:10:59

‚ÄĘ Added initial support for the Java Platform Module System: The¬†`native-image`¬†builder now accepts the module-related arguments known from the¬†`java`¬†launcher like¬†`-m`,¬†`-p`, and¬†`--add-opens`. When such a module-related argument is used, the image generator itself is used as a module too. This is a major change in how the image generator works, and development is still ongoing to support more aspects of the module system. Please provide feedback and bug reports when you try out this new feature. Can someone explain it to me ELI5?

Joshua Suskalo15:10:07

Do you understand the java platform module system and just want to know how it applies to native-image? Or do you need an explanation of modules?

Karol Wójcik15:10:51

I need explanation on both

Joshua Suskalo15:10:07

I can't help on how it's integrated into graal and how that affects native-image, but on the java side I can help

Joshua Suskalo15:10:45

The Java Platform Module System is the name for the project that was running since before JDK 7 was released, and that got integrated into JDK 9 and forced on users in JDK 11. Basically it adds a concept of a "module" which is a named group of packages where code inside the module is only allowed to access code from other modules that it declares a dependency on, and you can only access code from inside a module if it exposes it.

Joshua Suskalo15:10:02

This acts as a security feature that's very good, but it also allowed the JVM to be split into 94 separate pieces.

Joshua Suskalo15:10:41

With the tools jlink and jpackage you can produce trimmed down versions of the JVM with very small footprints (like <40mb for a minimal JVM) and package them for use on systems as native executables.

Joshua Suskalo15:10:51

Clojure has no explicit support for it, and all clojure code falls into the "unnamed module" by default. You can change this if you add some module metadata information in the form of a java file and compile it into your result jar file, but this would make your project incompatible with JDK 8, which (if I understand correctly) is why Clojure hasn't integrated it yet.

Joshua Suskalo15:10:45

the module system got a lot of flak because people who were relying on private internals of the JDK had their projects broken because the modules didn't export that private functionality, but besides that it's been a mostly positive change for security and distribution.

Karol Wójcik15:10:53

Thank you so much!

Karol Wójcik15:10:03

One question. How much the module system is used for regular web apps? I mean this is mostly used when you want to distribute your application for desktops?

Joshua Suskalo15:10:23

So if you're installing a whole JVM on your server and just running clojure code either as a jar or via the cli, you're basically not interacting with the module system.

Joshua Suskalo15:10:35

Same thing if you expect your desktop users to already have a JVM.

Joshua Suskalo15:10:57

The only way you're likely to interact with the module system is if you use a module that isn't packaged with the core jvm anymore, like JavaFX.

Joshua Suskalo15:10:27

so in those cases you'll need to have an --add-modules flag passed to the JVM, and maybe add a new jar to the path.

Joshua Suskalo15:10:05

The main way you'd interact with the module system for deployment on desktop is if you use jlink to produce a stripped-down jvm to distribute

Joshua Suskalo15:10:34

that way you don't need to rely on them having the right jvm

Joshua Suskalo16:10:26

you might also interact with the module system if you're trying to deploy to embedded hardware where the difference between a 200mb jvm and a 39 mb one makes a difference.

Karol Wójcik16:10:52

Does relying on modules somehow impacts the performance or startup time?

Joshua Suskalo16:10:27

I don't know for sure, but it seems unlikely. Most module security checks happen at compile time, so if you're not using reflection you pay no cost for those security checks, and the module system doesn't really change the JVM's code loading systems. If anything it might just allow you to load slightly less code at startup by making certain parts of the stdlib unavailable.

Joshua Suskalo16:10:07

also there's no way to "opt out" or "opt in" to the module system besides just using java 8 for no module system and >9 for having one

Joshua Suskalo16:10:25

it's just a part of how the JVM links now is all.

Joshua Suskalo15:10:35

fair enough. At the moment I'm using logback as my impl, but I could just as easily bring in timbre or a noop


perhaps logback works too, haven't used it with native-image

Joshua Suskalo15:10:30

but yeah, I have a glfw test program that should work if panama works on graalvm

Joshua Suskalo15:10:46

again assuming that the AOT thing fixes the problem with runtime bytecode generation


runtime bytecode generation?

Joshua Suskalo15:10:53

yeah, coffi generates bytecode at runtime to avoid reflection costs

Joshua Suskalo15:10:10

but it's only done when you create a handle to a native function, or want to generate an upcall handle to pass a callback


what are you referring to with AOT thing?

Joshua Suskalo15:10:31

Well all the bytecode generation besides passing a callback is actually done at library load time


I don't know if panama is supported in native image right now btw, curious to find out

Joshua Suskalo15:10:04

so theoretically it should just work because during the native image compilation it'll already have the classes

Joshua Suskalo15:10:50

dang, looks like graal for jdk17 isn't on the AUR yet, I'll have to wait till after work so I can get it installed and everything


@suskeyhose Hmm? You can just download a zip file, unzip it and set GRAALVM_HOME + JAVA_HOME to that dir?


That's how I do it, no package manager

Joshua Suskalo16:10:28

Probably, but it's during work hours and I didn't want to spend time figuring that out on company dime. ūüôā


Finished compiling bb with 21.3.0 + java 11 vs java 17. Java 11: about 10mb data reduction. Java 17: back to the same size as with 21.2.0 on Java 11 :)

ūüĎć 3
Karol Wójcik15:10:40

Do you see any performance improvements?

Karol Wójcik15:10:15

Both in the runtime and during the build time?

Joshua Suskalo15:10:13

does graal provide anything like jlink with the new module integration to allow you to strip it down to just what bb needs?

Joshua Suskalo15:10:24

or is it doing that automatically with like a tree shaker or something?


I believe it's doing that, they call it 'closed world analysis'


recent improvements... right from the release stream :)


yes, this is in the docs as well

Karol Wójcik15:10:33

GraalVM native-image includes classes/methods which are reachable during the build time

Karol Wójcik15:10:59

I'm still trying to understand what is this Java Platform Module System, though.


So far performance seems very similar


they have better optimizations available in enterprise version of graalvm... ūüėě so I believe if we could use it we would se few more percent. But it's what it is.


at least no regressions it seems

ūü§ě 1
Karol Wójcik16:10:56

Probably the AWS Lambda will see some cold start improvements, because build size is smaller. ūüėĄ


Interesting, why you think Java 17 is bigger?


I noticed the image in jdk17 is pulling in more java awt classes: while it should not pull in any java awt classes. I have to do more research why this is happening.


weird haha


ok, got rid of this.

partywombat 1

The warning spit out for --initialize-at-build-time has changed for v21.3.0:

--initialize-at-build-time without arguments has been deprecated when not using --diagnostics-mode. With GraalVM 22.0.0 --initialize-at-build-time will only work with --diagnostics-mode for debugging purposes.
The reason for deprecation is that --initalize-at-build-time does not compose, i.e., a single library can make assumptions that the whole classpath can be safely initialized at build time; that assumption is often incorrect.


Good warning


I know, right? I rarely see warnings with clear rationales!

Karol Wójcik18:10:37

We should start adjusting our Clojure libraries it seems.


I could not tell, since two projects in #clj-easy were pretty much all about that ;)

ūüėā 2
truestory 4
Karol Wójcik19:10:50

Forgotten we are using ‚ÄĒinitialize-at-build-time for Clojure namespaces XD

Karol Wójcik19:10:14

Too tired today ūüėāūüėā


@karol.wojcik are you maybe thinking something along these lines?

user=> (1 2)
My dear friend,

I'm afraid that I can't do that.

Let me explain why:
The first item after a left parentheses is expected to be a function.
You've specified the number 1 as the first item after the left parentheses, which is not a function.

To learn more about Clojure functions, see .




Oh @karol.wojcik I thought you meant we should start adjusting our libraries and Clojure with more verbose error messages. Maybe I’m tired, too! But the joke is still pretty funny.


@lee I love that error message. You should consider becoming a compiler/linter.


I could, yes, not a bad idea. Each message would be unique and personalized. Limit of 1 message per day.

Alex Miller (Clojure team)19:10:18

wouldn't you be disappointed to find out that that was already happening but I was just very unimaginative?

ūüėā 6

Ha! Golden!

Joshua Suskalo23:10:56

it's promising, graalvm for jdk 17 has the jdk.incubator.foreign module