Remove JNA and migrate to JNI or Project Panama

[magic-cucumber]

1. JNA bundles dynamic libraries for three different platforms by default. The total file size impact is significant and should not be overlooked.

2. Some users have encountered errors during JNA initialization for unknown reasons. (My old GitHub account was flagged; otherwise, I would link the specific issues where I addressed these JNA-related exceptions in my app.)

Regarding Native.getComponentID(c: Component)

This is a utility function built on top of the AWT Native API. It is used to retrieve window information corresponding to a component during the rendering process.

Because documentation and resources for the JAWT API are extremely scarce online, I am limited in the direct assistance I can provide.

If you intend to replace this function using JNI, you can refer to this implementation for guidance: https://github.com/magic-cucumber/webkit-panel-demo/blob/main/native/src/libs.mm (Note: The comments in this source file are in a non-English language).

[kdroidFilter]

It’s not JNA that bundles native libraries for three different platforms, it’s me.
In practice, there are essentially two ways to do this without unnecessarily bloating the application:

Either publish one package per OS and per architecture with the native binaries, and then, at runtime, select the correct one using the host triple.

Or strip the application afterward.

Stripping the app after the fact seems simpler to me. I’ll be releasing a Gradle plugin shortly that does exactly this. In the meantime, you can add a Gradle task like this:

// Host platform detection
val hostOs: String = System.getProperty("os.name") ?: error("Unable to detect OS")
val hostArch: String = System.getProperty("os.arch") ?: error("Unable to detect architecture")

// Native folder to keep based on platform
val nativeFolderToKeep: String = when {
    hostOs == "Mac OS X" && hostArch == "aarch64" -> "darwin-aarch64"
    hostOs == "Mac OS X" -> "darwin-x86-64"
    hostOs.startsWith("Windows") && hostArch == "amd64" -> "win32-x86-64"
    hostOs.startsWith("Windows") && hostArch == "aarch64" -> "win32-arm64"
    hostOs.startsWith("Windows") -> "win32-x86"
    hostOs == "Linux" && hostArch == "aarch64" -> "linux-arm64"
    hostOs == "Linux" -> "linux-x86-64"
    else -> error("Unsupported platform: $hostOs / $hostArch")
}

// All possible native folders in rodio
val allNativeFolders = listOf(
    "darwin-aarch64", "darwin-x86-64",
    "win32-x86-64", "win32-x86", "win32-arm64",
    "linux-x86-64", "linux-arm64"
)

// Folders to remove
val nativeFoldersToRemove = allNativeFolders - nativeFolderToKeep

// Task to clean JARs in the bundle after createDistributable
abstract class CleanBundleNativesTask : DefaultTask() {
    @get:Input
    abstract val folderToKeep: Property<String>

    @get:Input
    abstract val foldersToRemove: ListProperty<String>

    @get:InputDirectory
    @get:Optional
    abstract val appDir: DirectoryProperty

    @get:Internal
    abstract val tempDir: DirectoryProperty

    @TaskAction
    fun execute() {
        val appDirFile = appDir.get().asFile
        if (!appDirFile.exists()) {
            logger.warn("App directory does not exist: $appDirFile")
            return
        }

        val tempDirFile = tempDir.get().asFile
        val folders = foldersToRemove.get()

        logger.lifecycle("Native folder kept: ${folderToKeep.get()}")
        logger.lifecycle("Native folders removed: $folders")

        appDirFile.walkTopDown()
            .filter { it.isFile && it.extension == "jar" }
            .forEach { jarFile ->
                cleanJar(jarFile, tempDirFile, folders)
            }
    }

    private fun cleanJar(jarFile: File, tempDirFile: File, folders: List<String>) {
        var hasNativeFolders = false
        ZipFile(jarFile).use { zip ->
            hasNativeFolders = zip.entries().asSequence().any { entry: ZipEntry ->
                folders.any { folder -> entry.name.startsWith("$folder/") }
            }
        }

        if (!hasNativeFolders) return

        logger.lifecycle("Cleaning: ${jarFile.name}")

        tempDirFile.deleteRecursively()
        tempDirFile.mkdirs()

        var removedCount = 0

        ZipFile(jarFile).use { zip ->
            zip.entries().asSequence().forEach { entry: ZipEntry ->
                val shouldRemove = folders.any { folder -> entry.name.startsWith("$folder/") }
                if (shouldRemove) {
                    removedCount++
                    logger.info("  - Removed: ${entry.name}")
                } else {
                    val destFile = File(tempDirFile, entry.name)
                    if (entry.isDirectory) {
                        destFile.mkdirs()
                    } else {
                        destFile.parentFile?.mkdirs()
                        zip.getInputStream(entry).use { input ->
                            destFile.outputStream().use { output ->
                                input.copyTo(output)
                            }
                        }
                    }
                }
            }
        }

        if (removedCount > 0) {
            val originalSize = jarFile.length()
            jarFile.delete()
            ZipOutputStream(jarFile.outputStream()).use { zos ->
                tempDirFile.walkTopDown().filter { it.isFile }.forEach { file ->
                    val entryName = file.relativeTo(tempDirFile).path.replace("\\", "/")
                    zos.putNextEntry(ZipEntry(entryName))
                    file.inputStream().use { it.copyTo(zos) }
                    zos.closeEntry()
                }
            }
            val newSize = jarFile.length()
            logger.lifecycle("  → $removedCount files removed, ${(originalSize - newSize) / 1024} KB saved")
        }

        tempDirFile.deleteRecursively()
    }
}

// Create cleanup tasks for both main and release builds
data class BuildConfig(val buildType: String, val taskSuffix: String, val createTask: String, val packageTasks: List<String>)

listOf(
    BuildConfig("main", "", "createDistributable", listOf("packageDmg", "packageMsi", "packageDeb")),
    BuildConfig("main-release", "Release", "createReleaseDistributable", listOf("packageReleaseDmg", "packageReleaseMsi", "packageReleaseDeb"))
).forEach { config ->
    val cleanTask = tasks.register("cleanBundleNatives${config.taskSuffix}", CleanBundleNativesTask::class) {
        description = "Removes native binaries for non-targeted platforms from the ${config.buildType} bundle"
        group = "build"

        folderToKeep.set(nativeFolderToKeep)
        foldersToRemove.set(nativeFoldersToRemove)
        appDir.set(layout.buildDirectory.dir("compose/binaries/${config.buildType}/app"))
        tempDir.set(layout.buildDirectory.dir("tmp/native-cleanup-${config.buildType}"))
    }

    // Configure task dependencies
    afterEvaluate {
        tasks.findByName(config.createTask)?.let {
            cleanTask { dependsOn(it) }
        }
        config.packageTasks.forEach { taskName ->
            tasks.findByName(taskName)?.dependsOn(cleanTask)
        }
    }
}

Regarding the removal of JNA: I don’t use JNA directly. I use Gobley, which itself relies on JNA. Gobley is responsible for generating all the glue code.

At the moment, there is no sponsor for this library, and I don’t feel comfortable maintaining a library if I also have to maintain all the glue code myself, especially since that glue would have to be written either with JNI or Panama. If I write it with JNI, I’ll be asked to switch to Panama; if I write it with Panama, I’ll be asked for backward compatibility with JDK 21 or earlier.

So for now, as long as there isn’t someone willing to genuinely sponsor this library, I can’t accept this kind of task. I’m forced to stick to something simple and functional. I hope you understand.

As for the issues with JNA, we’d need to look at what they actually are. I use JNA in Compose Media Player and Compose Native Tray, and no particular issues have been reported so far. JNA has the advantage of being convenient and backward-compatible, especially since, in this case, Gobley seems to use JNA direct, which tends to cause fewer reflection-related problems.

As for the issues with JAWT, I agree that this library should not be using it, and should instead perform offscreen rendering, as I mentioned here: #2

[PMARZV]

Jetbrains is implementing a KotlinDesktopToolkit for managing window stuff in all desktop platforms using Rust, to be consumed by Kotlin, i'm sure an addition of a native webview for their library could help them and thus they could sponsor you, it would be nice of Jetbrains to sponsor libraries such as this for use in their IDEs and for Kotlin and Compose consumers.