I managed to get Compose working with GraalVM on m...

# compose-desktop

[אליהו הדס]

I managed to get Compose working with GraalVM on macOS (which seems to be the hardest platform to get working), Windows and Linux. Even though Leyden exists, I find it useful for apps that require very low RAM usage. I wonder if it’s worth implementing it in Nucleus. https://github.com/kdroidFilter/compose-graal-vm Here's the repo for a sample app;

[S.]

what was necessary to achieve it? I don't know much about it but from past messages it seemed like one of the main issues was that AWT was not supported by graalvm, so a different UI toolkit would be needed.

[אליהו הדס]

I used the Liberica native toolkit that support awt

[S.]

also, do you have a RAM comparison without using graal?

[אליהו הדס]

I know it's around 220-250, but I'll test that precisely.

[אליהו הדס]

I'll first try to see if it works under Windows and Linux.

[S.]

my live app easily exceeds 600MB, I'm all for cutting that down 😅

[אליהו הדס]

I don't know if it will change much in your case; you might reach 500MB, but if your app is CPU-intensive, you'll also have much lower performance. I think it's a small gain compared to everything you lose.

[אליהו הדס]

This is mainly for small apps that need to stay open all the time; I'm thinking of apps like JetBrains Toolbox, which in my opinion uses too much RAM for an app that's constantly running.

[S.]

yeah that makes sense. I wasn't aware of performance implications

[אליהו הדס]

I think it's good for applications that are mostly pure UI; I think we'll get better performance with pure UI, but certainly not for apps that need high computing power.

[אליהו הדס]

on windows it's very impressive

[אליהו הדס]

it's without graalvm

[אליהו הדס]

Another very interesting point is that the native graalvm executable, once compressed in zip, is approximately 25MB.

[אליהו הדס]

With packagers like NSIS that support higher compression formats, it can be very interesting.

[אליהו הדס]

I'm going to try to compile everything into a GitHub runner matrix

[אליהו הדס]

I think the biggest sticking point will be creating a stable decorated window that doesn't use the JBR APIs.

[S.]

oh JBR is not an option for graalvm?
how do the startup times compare to AOT cache? similar or is one significantly faster? (haven't tried leyden myself yet)

[אליהו הדס]

No, JBR doesn't support GraalVM; I'd say there's a 20 to 30% difference

[אליהו הדס]

Leyden remains very fast, and that's what I use for my large applications.

[אליהו הדס]

I tested it on a real mini application and it's very impressive.

[אליהו הדס]

https://github.com/kdroidFilter/compose-graal-vm Here's the repo for a sample app

[Thomas]

Nice, I'm actually using GraalVM on Windows and Linux in production for two of my apps. It's working great, but writing the agent tests was lots of work to handle edge cases. For macOS I decided to use kotlin native instead.

[אליהו הדס]

@Thomas Do you use JNA a lot?

[seb]

Really cool exploration! Sadly no JBR == no Jewel :(

[אליהו הדס]

@seb Is jbr not only necessary for the decorated window?

[seb]

At this point there are so many things that won't work properly outside the JBR, like font loading on Windows and Linux doesn't work correctly on other JVMs

[seb]

There is no way to match a Compose font family and an AWT font because JVMs use the wrong ttf field as font name lol

[seb]

HiDPI/density support is also missing/lacklustre on other JVMs

[Michael Paus]

@seb What exactly isn't working with HiDPI? I haven't noticed any problems on my retina macs with Zulu 25 for example. Do you have issue numbers?

[seb]

I have been told it's primarily when you have multiple screens with different densities (and especially on Linux)

[seb]

On other VMs I also have seen bitmap corruptions and weird visual glitches over the years

[אליהו הדס]

@seb Theoretically, we should be able to do all of this via JNI, right? Personally, using GraalVM is only really worthwhile on Windows, because Windows is really, really (like, really) slow at compiling JIT , whereas Leyden on Mac and Linux is instantaneous.

[seb]

Those may be fixed or not

[seb]

I haven't used Leyden @אליהו הדס so I have no context here but yeah, at least on windows it should be possible to use JNI for some of these issues. But you can't hot-patch the JVM you're running on to parse TTF correctly for example

[seb]

And in general, if you look at the JBR API GitHub repo you get an idea of what is missing in terms of features on other JVMs

[seb]

(I also suspect there's quite a different level of maintenance of the UI stack and its perf on JBR compared to other JVMs but I have no hard data here)

[אליהו הדס]

@seb But the issue with TTF files is only relevant if I want to load system fonts, right?

[Michael Paus]

I just don't like the idea of the "write once, run anywhere" to become "write once and only run on JBR" 🧐.

[אליהו הדס]

@Michael Paus No, I disagree. OpenJDK hasn’t cared about desktop apps with the JVM for the past 15 years.

[אליהו הדס]

Have you seen the system tray? It’s the same one from Windows XP.

[אליהו הדס]

maybe windows 95

[seb]

Yeah that is the sad reality, JBR is the only JVM that cares at all about desktop UI.

[seb]

Swing code has been largely left untouched in the other JVMs since the mid-00s

[seb]

JetBrains has an obvious interest in keeping their JBR working well for UI and do a ton of testing and continuous improvements — the only ones as far as I know who invest on it

[seb]

Last year they did a ton of work to enable proper a11y/screen reader support on Linux for example, which has never worked well on JVM

[seb]

Maybe some of it will eventually make it into other JVMs, but it is unlikely — not because JetBrains don't care, but because by and large other JVMs do not care about mainlining

[seb]

The JBR fundamentally exists because others have stopped caring

[אליהו הדס]

Personally, I don't understand why Compose doesn't recommend JBR. I saw in the accessibility code that it uses JBR and provides fallbacks if it's a different JVM, but this isn't mentioned anywhere.

[seb]

Last I checked they do not want core Compose to depend on JBR

[Michael Paus]

I don't disagree with the facts but nevertheless I also don't like this move away from a unified Java platform. Getting something into the JDK is harder than just doing it outside but at leaset one should try.

[seb]

Not as a hard dependency

[seb]

Michael, the people working at JetBrains used to work at Sun in St Petersburg, you think they wouldn't?

[seb]

If Oracle is not receptive, they can't force things in

[seb]

Again, JBR exists not because JetBrains doesn't care, but because others do not

[אליהו הדס]

Not as a hard dependency

But why? What's the problem with forcing the use of JBR? In the Compose plugin, I saw code for JDK <16.

[seb]

They see things like Michael I guess 😄

[seb]

I don't know, they might have an official stance I am not aware of, and do not want to put anything into anyone else's mouth here

[seb]

My read of the situation is that above

[אליהו הדס]

I think it's better to focus on a single platform, simplify the code, and add more features. Decorated windows are, for me, a must-have that's hidden in the billions of lines of IntelliJ code without being documented.

[seb]

We have extracted the core bits in Jewel at least 😄

[S.]

Hot reload already depends on the JBR.
And since we need to bundle a JVM anyway I don't see an issue either

[seb]

Hot Reload technically depends on DCEVM, the fact that JBR is the only JVM that implements it is again this

[seb]

Also to note, Hot Reload is not maintained by the core CMP team, but by the wider Kotlin team

[אליהו הדס]

On macOS, I ran the demo of Jewel with my own implementation of a decorated window, and it seems to work very well; I'll test it with GraalVM.

[אליהו הדס]

it seem to work

[seb]

nice! the dropdown in the title bar looks a bit odd but that's probably not graalvm

[אליהו הדס]

no it's my decorated window 🙂

[אליהו הדס]

but you load all your icons via reflection !

[אליהו הדס]

If we had a plugin like this that could automatically resolve all the reflection without having to do it manually with an agent, that would be great; otherwise, it's really only for power users.

[אליהו הדס]

(I'm living in Israel 15 years ago and i'm 29 🙂 )

[seb]

Icon loading is being redone at the IJPL level to better support Compose/Jewel :)

[אליהו הדס]

I don't know if it's clear in the video, but the GraalVM version (on the left) has a lot of trouble managing the lazy column of 1 million elements, unlike the JVM version which handles it without any problem. In fact, as you can see, the GraalVM version completely crashed. So, as I said, it should be reserved for small applications that need to start instantly and have very low RAM usage, but otherwise the JVM remains much more efficient.

Enregistrement de l’écran 2026-02-25 à 15.37.08.mov

[אליהו הדס]

@seb jewel + graalvm on windows 🙂

[seb]

Awesome stuff mate, thanks for pushing the envelope ❤️

[אליהו הדס]

Yes! 🙂 I'll publish all of this soon.

[אליהו הדס]

But it took me 4 hours with your font loading system under Windows! 😵‍💫

[seb]

It's a pain I know

[seb]

Took me weeks to figure out to begin with

[אליהו הדס]

I would like to try compiler a real application that uses Jewel with GraalVM

[אליהו הדס]

I certainly won't distribute it, but I want to see if it's possible; it'll be fun.

[אליהו הדס]

I could write an article about it 🙂

[seb]

I'd love to read it

[אליהו הדס]

I wrote my first article on Compose Desktop a while ago; I think you'll like it.

[אליהו הדס]

@seb I managed to get HDPI support under Windows and Linux with GraalVM ! 🎉

[אליהו הדס]

I’m starting to believe that it could really be usable

[אליהו הדס]

what is funny, is that the application detects the change of theme before the windows apps 🙂

Enregistrement de l'écran 2026-02-26 210217.mp4

[seb]

Awesome!

[seb]

Waiting for a blog article and a ready-to-use library 😄

[seb]

Wonder if you can also get GraalVM not to crash with larger apps

[אליהו הדס]

I think that if we use aot, we should not load 1 million objects at once but pagination 😅

[אליהו הדס]

even in a JVM, I am not sure that it is a good practice 😬

[seb]

Ehehe well that is an intentional stress test :P

[אליהו הדס]

I understood well 😅

[efemoney]

Thanks for this thread guys!

[אליהו הדס]

@seb I managed to compile an average app that uses Jewel and Lucene with graalvm 🙂 and for the moment no bug has been reported

[אליהו הדס]

sorry, it's hebrew only

Enregistrement de l'écran 2026-02-27 100934.mp4

[אליהו הדס]

and this is with jvm

[אליהו הדס]

afterward I know that a lot of dev use koin, and I wonder if it will break with graalvm, but since I’m using metro there’s no problem, personally I don’t have anything to test with koin

[seb]

Same here, Metro ftw

[אליהו הדס]

my intuition is that it is perfectly possible to make a plugin that compiles the app with graalvm and that would work out of the box for all kmp libs since they do not use reflection in the vast majority of cases, and when we have jvm only dependencies, it would need to be configured manually, I think that could be interesting. Compose would directly attack flutter in the size of binaries, the startup speed, and the perfs in pure ui on desktop, and would surpass it. (except in the size of the binary) , it would be cool to find a sponsor

[אליהו הדס]

for now I just think about publishing an experimental version of nucleus that will support graalvm and that will ask the developer to be extremely careful

[אליהו הדס]

On the left it is with graalvm, on the right it’s jvm + leyden with proguard (jvm about 40mb, leyden 20mb)

[אליהו הדס]

I also note that the graalvm compilation is faster than the progard optimization

[Michael Paus]

What has actually been changed so that this seems to be working now? Several years ago I made some efforts myself to get that working but at that time it seemed to be not possible. See: https://kotlinlang.slack.com/archives/C01D6HTPATV/p1675614566722809?thread_ts=1675578052.700349&amp;cid=C01D6HTPATV

[אליהו הדס]

@Michael Paus maybe it improved with the JDK 25 from liberica

[אליהו הדס]

And I don't think it was configured correctly; the libraries need to be in very specific locations, it's a bit strange even, it took me a while to find the right configuration.

[אליהו הדס]

All the libs must be located next to the executable, except for jawt, if I remember correctly, which must be in a lib folder. I wonder if such a configuration will be accepted by the Mac App Store.

[Michael Paus]

As far as I understand the issue binary lib files must come with the application and must reside inside the app-folder. A common scheme like extracting them at run-time from a jar and place them into a temporary folder doesn't work.

[אליהו הדס]

Yes, that's it. My Nucleus plugin will handle that out of the box. The question is, will it be accepted by the Mac App Store?

[Michael Paus]

I don't know for sure because I don't use the App Store. I just stick to the above rules and notarize my apps for self-distribution. That works. I don't know if notarization has the same requirements as the App Store here.

[אליהו הדס]

yes it's fine for notorization but native libs have to be in Content/Framework for the mac app store

[אליהו הדס]

I don't know if it's just a convention

[Michael Paus]

At least for notarization they don't have to be in Content/Framework.

[Alexander Maryanovsky]

Personally, I don’t understand why Compose doesn’t recommend JBR. I saw in the accessibility code that it uses JBR and provides fallbacks if it’s a different JVM, but this isn’t mentioned anywhere.

We just haven’t made the decision, officially.
Personally, I would recommend JBR for CfD apps, and I use it myself in my pet project.

[אליהו הדס]

The most annoying thing is the HDPI; nowadays all laptops have an HDPI display. If it's Windows, then it's blurry, and if it's Linux, it's extremely small. JBR isn't an option in my opinion.

[אליהו הדס]

On Windows, I've seen that with the Liberica JDK, I don't have this problem, but they've done a lot of optimizations for Swing and JavaFX; I don't know about other JDKs. But with linux only jbr support hdpi

[seb]

Yeah realistically you can only get consistently good results across platforms with the JBR.

[אליהו הדס]

We're still waiting for touchscreen support 😬

[אליהו הדס]

I'm getting loads of msg saying the touchscreen isn't working properly. I tell them that the day Apple releases a touchscreen MacBook Pro, JB will support it too 😂

[Michael Paus]

Maybe Apple was listening to you:

https://www.youtube.com/watch?v=5AAjWlomscw▾

[Alexander Maryanovsky]

god no

[אליהו הדס]

god no

Because you know you'll have to put up with the touchscreen, or because a laptop with a touchscreen is absolutely awful and useless?

[Alexander Maryanovsky]

Imagine the amount of bugs you can have when you have a screen with any number of touch pointers PLUS a mouse pointer.

[Alexander Maryanovsky]

Because you know you’ll have to put up with the touchscreen, or because a laptop with a touchscreen is absolutely awful and useless?

Both

[אליהו הדס]

Steve Jobs is missed; they are tarnishing his name. 😭

[Michael Paus]

Don't blame me. I am just the messenger 😇. I agree with you but when Apple comes up with that we will sooner or later have to cope with it.

[אליהו הדס]

@Michael Paus Well yes, in two years, we’ll all have touch-screen Macs and we’ll say it’s amazing, even a revolution.

[אליהו הדס]

That’s exactly what I’m saying: as long as Apple doesn’t release a touch-screen Mac, then touch-screen laptops “don’t exist,” so there’s no need to bother implementing it.

[אליהו הדס]

@seb Were you able to test Jewel with GraalVM?

[seb]

No I do not have time for that these days, I may in the future but I'm pretty swamped 🙂

[אליהו הדס]

thank you very much! it’s mainly the workaround that I did regarding the fonts, I wonder if it’s problematic what I did

[seb]

If it works on Windows it's probably fine 😄

[seb]

macOS is the one that ~works on all OSes since JVMs use the system APIs for fonts instead of manual parsing

[seb]

Windows/Linux the JVM manually parses (badly)

[אליהו הדס]

https://github.com/kdroidFilter/Nucleus/tree/main/graalvm-runtime/src/main/java/io/github/kdroidfilter/nucleus/graalvm/font if you have the time to verify this, if it’s correct and doesn’t generate bugs, that would be super cool

[seb]

I did that work 2y ago so I don't remember all the subtleties 😄 I don't want to commit to it since I honestly don't know when I'll have time — I am pushing back on reviews at work too and have like 16 pending Jewel PR reviews to do 🫠

[seb]

I'd rather not say I'll do it when I don't know when

[seb]

Out of respect

[אליהו הדס]

Thank you very much. In any case, I think that since I'm an adventurer, the next version of my app will be distributed with GraalVM, so we'll see 😅

[seb]

Best of luck 🙂 I'll be keeping an eye on your progress for sure 🙂