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

Amazing! Thanks!

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?

I need explanation on both

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

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.

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

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.

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.

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.

Well explained!

Thank you so much!

No problem!

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?

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.

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

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.

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.

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

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

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.

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

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.

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

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

runtime bytecode generation?

yeah, coffi generates bytecode at runtime to avoid reflection costs

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?

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

ok

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

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

yeah, me too

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?

https://github.com/graalvm/graalvm-ce-builds/releases/tag/vm-21.3.0

That's how I do it, no package manager

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

sure

Do you see any performance improvements?

Both in the runtime and during the build time?

I'll check

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

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

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

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

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: https://github.com/babashka/babashka/issues/1052#issuecomment-960182315 while it should not pull in any java awt classes. I have to do more research why this is happening.

weird haha

ok, -H:ServiceLoaderFeatureExcludeServices=java.net.ContentHandlerFactory got rid of this.