I'm using the <Compose multi-platform template> wi...
# compose-desktop
s
I'm using the Compose multi-platform template with Android Studio as my IDE and trying to add Java compile time arguments to the desktop app task (
./gradlew :desktopApp:run
). The reason is I want to export Apple EAWT classes to enable me to use touchpad gestures as well as set a custom handler on the default About menu item. I'm beating my head against a wall though, have googled like crazy but no method seems to work. Does anyone know how to add Java compile time arguments to the desktop app Gradle task? Thanks in advance. 🙂 I tried both the
jvmArgs
and
args
inside
compose.desktop { application } }
but I think that is just setting the runtime JVM arguments and program runtime arguments, I also unsuccessfully tried stuff like this inside the desktop Gradle build file:
Copy code
tasks.withType<JavaCompile> {
    val compilerArgs = options.compilerArgs
    compilerArgs.add("--add-exports java.desktop/com.apple.eawt=ALL_UNNAMED")
}
No matter what I do, I still end up getting a problem like this:
Copy code
Exception in thread "main" java.lang.IllegalAccessError: class com.test.test.ComposableSingletons$MainKt$lambda-1$1 (in unnamed module @0x7ee7980d) cannot access class com.apple.eawt.Application (in module java.desktop) because module java.desktop does not export com.apple.eawt to unnamed module @0x7ee7980d
	at com.bontouch.bonteams.ComposableSingletons$MainKt$lambda-1$1.invoke(main.kt:22)
a
I don’t think you can solve that
The java.desktop module is already compiled and it’s not exporting that package.
s
Hi Alexander! Thanks for your reply. I have now tried creating a stand-alone Compose for Desktop project using the IntellliJ wizard, and used the corresponding compiler arguments in the run configuration per this post. That worked fine actually 🎉, so I am convinced there must be some way to make it work within the normal Gradle task as well and not just a custom run configuration for the main class, but still pass the compiler options somehow, right?
When you say the java.desktop module is already compiled -- surely that would also then be the case also with the IntelliJ managed run configuration? Yet that still somehow works.
After further testing, in IntelliJ only and only using the IntellIJ wizard to create the project, I can generalise the question as the following: In a stand-alone Compose Desktop project (with no other modules, i.e. no Android or iOS) generated by the IntelliJ wizard for Compose Desktop projects, then passing the following works fine in the Kotlin > MainKt run configuration to gain access to custom Apple classes: VM options: --add-opens java.desktop/com.apple.eawt.event=ALL-UNNAMED Program arguments: -XDignore.symbol.file --add-exports java.desktop/com.apple.eawt.event=ALL-UNNAMED However, I am unable to -- in the same project, or any other project -- pass those same arguments through to the Gradle run task. Surely there must be a way to do it?
I now managed to grab logs holding the full command line launched by: the MainKT manual launch configuration the Gradle run configuration ...both for the same project. I separated each argument on its own line, and normalised them by tweaking formatting, and sorted them, and then compared them (working manual launch config to the left, non-working Gradle config to the right). Looks almost identical, yet the exports work just fine in the manual launch config, and cause an exception about missing exports in the Gradle run config. Really strange. I also compared the contents of the compiled project classes snapshot in the two cases (one is referencing a snapshot JAR, the other is referencing a folder of classes) -- both completely identical except one also has an (empty) manifest.
I finally solved it:
_compose_._desktop_ *{*
application *{*
mainClass = "MainKt"
jvmArgs("--add-opens=java.desktop/com.apple.eawt.event=ALL-UNNAMED")
args("-XDignore.symbol.file --add-exports java.desktop/com.apple.eawt.event=ALL-UNNAMED")
The key was to add a
=
between
--add-opens
and the package name. I have no idea why this was needed for the Gradle task but not for the manual launch job, they looked identical in the final logs. Must be some weird difference of invocation.
👍 1