So umm, what does <https://openjdk.org/jeps/472> s...

# compose-desktop

[Kirill Grouchnikov]

So umm, what does https://openjdk.org/jeps/472 spell for CoD and specifically for Skiko down the line?

Prepare the Java ecosystem for a future release that disallows interoperation with native code by default, whether via JNI or the FFM API. As of that release, application developers will have to explicitly enable the use of JNI and the FFM API at startup.

Might be too soon of course to be asking this

[ephemient]

from the same document,

Most application developers will pass --enable-native-access directly to the java launcher in a startup script

[Adam Brown]

even more reason for CfD to support native desktop targets and ditch the JVM all together 😜

[efemoney]

Unrelated: Isn’t the abbreviation CfD? 💀 I initially thought what is Call of Duty doing in this Kotlin slack

[Michael Paus]

@Adam Brown That sounds like a very bad bargain to me. You are trading 30 years of Java experience, libraries and tools against a single command line argument 🧐🙃.

[Kirill Grouchnikov]

For desktop, on desktop, now multiplatform…

[Adam Brown]

CMP now?

[Adam Brown]

packaging run times with what should just be an exe is a huge pain to me. Requires complex packaging steps for distributions, bloats the finals distro size, has worse startup times. JVM, JS, what ever. I would always prefer a simple exe to a more complex packaged system

[mikehearn]

Kotlin/Native won't fix any of that unfortunately. It's the same for any platform, Electron too. Native apps all require the same things these days, a single EXE file was barely workable even in the Win3.1 days.

Now that said, on macOS the app will look like a single file to your users, and on Windows if you use Conveyor your users can treat the generated exe file as if it were a single exe, because it'll download, install/upgrade and run the app when executed, or just run it if already installed. So it looks conceptually like one file. The only difference is uninstalling by dragging to the recycle bin doesn't work.

[Adam Brown]

having some DLLs next to the exe is fine, double clicking on the exe "just works". As opposed to a jar sitting in a directory. Now you need java on your path, and you have to pass a huge class path in, or we package a JVM with it which bloats the size, ect ect. I agree that electron is largely the same problem. But it sounds like other than the Swing windowing code, CMP is so close to being able to get away from this paradigm of shipping bloated binaries with their own run times.

[mikehearn]

It just statically links the Kotlin runtime into the app, it's not really a different model, just the code ends up in different files. The approach Conveyor uses on Windows does give the "click the exe and it just works" feel, you don't even need to have a zip or DLLs next to it. And it handles updates, which the "just make it an exe" doesn't because on Windows EXEs cannot update themselves easily due to file locking. The main thing it lacks is a good story around cleanup. A long time ago I wanted to introduce a mode where apps would uninstall themselves if they weren't used for a while and then reinstall if used again, so you could install apps worry-free. We never implemented it, but perhaps it'd be neat to revisit that idea.

[Adam Brown]

true enough on all of the update stuff, but on the kotlin runtime being linked in, sure, C++ technically links in it's runtime as well, albeit lighter weight, no GC and such. But I think that's materially different from a JS or JVM runtime. JVM in particular was never meant to be embedded per EXE, and we need to go through contortions and 3rd party tools to make it work.

Go being able to just produce EXEs is a huge advantage for many use cases. Sure there are use cases where we want a more complex packaging solution to handle updates and what not, but I don't think that negates the other use cases where we want something simpler and purely native.