:wave: I have an embedded device running Linux tha...

# compose-desktop

[Eric]

👋 I have an embedded device running Linux that doesn’t have a ton of available space (around 150Mb) and I’d like to run a Compose Desktop app on it if possible. The first issue I’m encountering is that the device doesn’t currently have Java installed. I see three initial options:
1. Install some minimal version of Java that’s smaller than the 300Mb full JDK. Based on the libjvm.so generated for other projects, it seems like there should be some version that’s <50Mb, but my Google-fu has failed in determining how to dissect just the runtime parts from the JDKs.
2. Include the JVM with the Compose Desktop application using libjvm.so. Is this an option somehow?
3. Compile the Compose Desktop application as fully-native. This seems ideal, but also appears to be a ways off.
Any thoughts? TIA

[romainguy]

The Java runtime only is called JRE. You don't have to create it yourself

[Eric]

I’ve found the ones from Adoptium and Azul, but they’re about 150Mb when expanded still

[Eric]

I think what I want is a way to run jlink and include my own modules file, which is I think what the MacOS desktop builds do. But I don’t see the same for the linux build

[Eric]

I think I’ve made progress on this and on to new problems. Appreciate the help.

[mcpiroman]

jlink/jpackage should be able to generate minimal JRE alongside your app. On windows it is around 40MB.

[Michael Paus]

When you can build your app with the standard Compose Gradle tasks, then you should be able to specify the exact java modules that you need like this.

compose.desktop {
    application {
        mainClass = "MainKt"
        nativeDistributions {
            modules("java.base","java.naming","java.prefs","java.scripting","java.sql","jdk.jfr","jdk.unsupported","jdk.unsupported.desktop","<http://jdk.crypto.ec|jdk.crypto.ec>","jdk.localedata")
...

By making the modules list as short as possible this should result in the smallest possible app based on Java without going native.

[mikehearn]

If you use Conveyor to build your packages then it'll do this scan for you to auto-shrink the bundled JVM. However, Conveyor doesn't currently support Linux ARM and would generate a deb, which might not be what you want. We could probably add support for Linux ARM quite easily - it's a little unclear how people want to distribute and update embedded Linux apps. There's a range of solutions out there.

[Michael Paus]

How can Conveyor do automatically what is actually impossible to do? Via static analysis you cannot find all dependent modules for the general case. Think of reflection, services, etc. You can get a proposal for a list of modules but this normally needs some manual tweeking to be usable.

[mikehearn]

Yes, it uses jdeps to do a static analysis and then you can patch up the results if it isn't accurate. We add the ECC module by default for example because it's basically always needed (for TLS). Mostly though, the static analysis does work. It's rare to use JDK modules purely via reflection outside of extra cryptography.