Publish JNI bindings to Maven Central

[link2xt]

Chatmail core currently has official Python and Node.js bindings published to PyPI and NPM. Maven Cental is the de facto primary repository for Java since JCenter has been shutdown.

JNI bindings exist, but are only used by Delta Chat for Android at https://github.com/deltachat/deltachat-android/tree/5117b70c589fc11b5239680dabaa4f07668072db/jni
There are users trying to JNI bindings in another chatmail client and they currently do this by copying the bindings from Delta Chat for Android repository: https://support.delta.chat/t/developing-with-chatmail-core-on-android-no-events-coming-in/4185

I think we should create a separate repository with chatmail core as a Git submodule so we can directly copy existing structure from deltachat-android repo with minimal modifications. Creating the issue here in chatmail core tracker only because there is no dedicated tracker yet.

As for licensing, chatmail core and all its bindings are MPLv2-licensed and JNI bindings don't have any GPL code that comes from Signal, so we can copy-paste MPLv2 from the core repo. Since deltachat/deltachat-android#3925 is merged JNI bindings also contain code generated with https://github.com/chatmail/dcrpcgen, this also needs to be changed to MPLv2 as it contains templates from which bindings are generated.
There are two exceptions:

• src/main/java/com/b44t/messenger/util/concurrent/ListenableFuture.java
• src/main/java/com/b44t/messenger/util/concurrent/SettableFuture.java

These two files originate from the Signal messenger, this can be seen in the original commit in Delta Chat Android repo. They are trivial, but ideally we should be able to get rid of them, also because they are nearly trivial.

I have started something at https://github.com/chatmail/jni/ by copying the code from the current main branch at deltachat/deltachat-android@dfef2b4

Documentation for publishing:

• https://docs.gradle.org/current/userguide/publishing_setup.html
• https://maven.apache.org/repository/guide-central-repository-upload.html

[Simon-Laux]

I attempted to make a standalone package for java (not really android specific) together with @ben-mor 4 years ago before the jsonrpc api really existed: https://github.com/ben-mor/dc-jni-playground

I don't know if it contains anything useful, it is 4 years old after all and targets core 1.56.

There is also some discussion on standalone java bindings in deltachat-bot/echo#9 for usage in bots.

[bleonard252]

For what it's worth, the existing JNI bindings in the Android app are still missing a lot, such as constants and a few functions that are available in the C API (one of the account creation ones?). Ideally, JNI and (most?) other FFI bindings should be auto-generated in general. (Would uniffi be a good idea?)

I expect that an auto-generated JNI binding would break deltachat-android nine ways from Sunday, but for new applications, it would be considerably easier to maintain.

[Simon-Laux]

FFI bindings should be auto-generated

I completely agree and that's one of the ideas with jsonrpc, but generators for it are not ready for other languages besides typescript (and now also java, but I haven't used it yet so I personally can't tell how good/complete that is; but @adbenitez will know that).

(Would uniffi be a good idea?)

cffi-api (including the header file) is proudly handwritten, I personally don't think this will change, because it would need to be rewritten or migrated by hand to work with a generator/bindings-system like uniffi. Also the cffi api has some limitations, so for improving the API I would rather invest more in improving the jsonrpc api, which is linker and transport independent (you can run it in separate processes or even separate computers).
You can read more about the reasoning why we made the jsonrpc api: https://delta.chat/en/2025-02-11-why-jsonrpc-bindings-exist

[r10s]

while publishing JNI bindings to Maven Central may make things easier for 3rd parties, it will slow down development of new core features, just because more repos are involved and complexity increases

me, for example, prototyping quite some things, has no idea about maven and whatnot. but i can handle the current situation with chatmail/core and deltachat-android. of course, also as i have done it for years.

therefore, it is crucial that there is a clear, documented way to use a local branch of core easily, including bindings.

For what it's worth, the existing JNI bindings in the Android app are still missing a lot

this would not be fixed by auto-generation, newer api, esp. with complex parameters/returns are using jsonrpc - which then can be used by dc_jsonrpc_request() already today (android is the flagship feature-wise, so there is not really sth missing :)

so auto-generation is unrelate to the original issue above

[adbenitez]

having a maven package will help a lot also with android development because then updating core is as simple as updating a version number in the build.gradle, also help with making build more reproducible, right now it depends on the developer being very careful

this will not help with testing non-released cores tho, but there are ways to include dependencies from local folders instead of maven so this shouldn't make it much worse than current situation