Rework library loading with a focus on cross-platform support

JFronny commented

2025-05-03 14:30:02 +02:00

(Migrated from github.com)

This PR does several things that, in combination, enable the behaviors I described in #216:

The Platform class was cleaned up to use an Enum instead. This simplifies platform checks, but if you want this to be in a separate PR, that is possible too.
The windows-gtk CI script was extended to generate dependency metadata in a simple, text-based format. This uses the dumpbin tool shipped with the preinstalled Visual Studio workloads, so it is easy to do in CI even if we can't do it on the end users device.
The generated metadata is ingested by LibLoad to automatically load dependencies before the dependent as needed.
LibLoad was updated to make javagi.path take precedence over the system path and to not override that (this property wasn't respected by the JVM anyway and probably just broke other libraries)
LibLoad was extended to support loading libraries from the classpath. This should allow java-gi to provide a new module for Windows (or MacOS) that contains pre-compiled binaries, drastically lowering the amount of work needed to get started on Windows. (I don't know whether you'd want this to be published to maven or elsewhere, so I haven't set up this module yet)
LibLoad was modified to use SymbolLookup, allowing the wrapper in Interop to be cleaned up a bit.

Closes #216

This PR does several things that, in combination, enable the behaviors I described in #216: - The Platform class was cleaned up to use an Enum instead. This simplifies platform checks, but if you want this to be in a separate PR, that is possible too. - The `windows-gtk` CI script was extended to generate dependency metadata in a simple, text-based format. This uses the `dumpbin` tool shipped with the preinstalled Visual Studio workloads, so it is easy to do in CI even if we can't do it on the end users device. - The generated metadata is ingested by `LibLoad` to automatically load dependencies before the dependent as needed. - `LibLoad` was updated to make `javagi.path` take precedence over the system path and to not override that (this property wasn't respected by the JVM anyway and probably just broke other libraries) - `LibLoad` was extended to support loading libraries from the classpath. This should allow java-gi to provide a new module for Windows (or MacOS) that contains pre-compiled binaries, drastically lowering the amount of work needed to get started on Windows. (I don't know whether you'd want this to be published to maven or elsewhere, so I haven't set up this module yet) - `LibLoad` was modified to use `SymbolLookup`, allowing the wrapper in `Interop` to be cleaned up a bit. Closes #216

jwharm commented

2025-05-04 19:49:11 +02:00

(Migrated from github.com)

Thanks for the PR! I'll review and test it, but in the long term I think maybe we should split LibLoad into its own little project. Primarily because correctly loading DLLs is not specific to java-gi. Secondly, I am not sure I am able to properly support java-gi on Windows and macOS; right now it kinda works but I personally care mostly about the GNOME environment (developing GNOME apps in Java/Kotlin/...) and I don't have the time or experience to properly support Windows and macOS (even though it currently mostly works).

JFronny commented

2025-05-04 22:02:25 +02:00

(Migrated from github.com)

I don't want to spend my time with Windows either, but unfortunately that seems to be where most of my users are, so I'm kind of stuck with it.
To me, the best course of action seems to be supporting Windows on a best-effort basis (ie I'll open issues and try to create PRs if I notice anything breaking, and if none are opened, its probably fine)
Perhaps the CI can run some basic sanity checks vis JUnit but more than that shouldn't be needed.

On extracting LibLoad: I'm inclined to agree. The code I'm using here is based on similar code for another project that effectively had to reimplement the same thing. Sharing this code seems like a good idea, especially since it is a bit finicky.

I don't want to spend my time with Windows either, but unfortunately that seems to be where most of my users are, so I'm kind of stuck with it. To me, the best course of action seems to be supporting Windows on a best-effort basis (ie I'll open issues and try to create PRs if I notice anything breaking, and if none are opened, its probably fine) Perhaps the CI can run some basic sanity checks vis JUnit but more than that shouldn't be needed. On extracting LibLoad: I'm inclined to agree. The code I'm using here is based on similar code for another project that effectively had to reimplement the same thing. Sharing this code seems like a good idea, especially since it is a bit finicky.

jwharm commented

2025-05-04 22:28:38 +02:00

(Migrated from github.com)

@JFronny The action failed: https://github.com/jwharm/java-gi/actions/runs/14824869031/job/41616684759

jwharm commented

2025-05-04 22:33:37 +02:00

(Migrated from github.com)

On extracting LibLoad: I'm inclined to agree. The code I'm using here is based on similar code for another project that effectively had to reimplement the same thing. Sharing this code seems like a good idea, especially since it is a bit finicky.

I can create a new GitHub project, something like "jwharm/win-lib-load" and grant you commit access so you don't need to create PRs. I can already publish the releases on Maven Central for the io.github.jwharm.* namespace, so that part would be easy.

> On extracting LibLoad: I'm inclined to agree. The code I'm using here is based on similar code for another project that effectively had to reimplement the same thing. Sharing this code seems like a good idea, especially since it is a bit finicky. I can create a new GitHub project, something like "jwharm/win-lib-load" and grant you commit access so you don't need to create PRs. I can already publish the releases on Maven Central for the io.github.jwharm.* namespace, so that part would be easy.

👍 1

Rows
Columns

Rework library loading with a focus on cross-platform support #219