The issue with Syncthing was that the author didn't want to call out to scoped storage APIs in Java and wanted to use only Go at any cost.

The performance is a bit worse but for background syncing it's not material.

> wanted to use only Go at any cost

An alternate spin on this is that a project than runs on around ten operating systems would like to maintain a common codebase for its core functionality.

Not a Java dev...

How would one use the Java APIs from a Go application?

I'm used to the reverse, Java calling external library.

The same way, just with the native side of JNI API.

Usually you'd make a Java/Kotlin/Whatever class that does the JVM code (e.g. calls out to Android, retrieves the list of files, processes that and prepares the most reasonable subset of data to be passed into Go world) and then use JNI APIs to instantiate it and call it.

(Alternatively, you can instantiate such a proxy class at app startup and pass it into Go world when you call into it for the first time.)

Ah ok.

Still, that would be a very large change to incorporate, given the current Syncthing app is just a light wrapper of the main Go application as I understand it.

Yes and it doesn't work with native code, so you have to implement an entire filesystem abstraction using Kotlin or Java.