Provide bindings for ICal-GLib-3.0

[tintou]

I've come across people wanting to revive bindings for libical while libical-glib exists and has introspection support, I tried to create bindings for it using java-gi but failed with errors.

It seems like it is a good candidate for more java-gi testing.

Se the conversation in libical/libical#834

[jwharm]

Thanks for trying out java-gi!

I tried to generate bindings from the ICal and ICalGLib gir files, and it uncovered a few bugs in java-gi that have now been fixed in the main branch.

I don't want to extend the java-gi repository to publish bindings for every GObject-based library in the world. People will expect support for those bindings, that I cannot provide.

So I went a different route: The upcoming version of java-gi will include a command-line tool to generate Java bindings from a gir file. You can already use it today from the main branch:

git clone --recurse-submodules https://github.com/jwharm/java-gi.git
cd java-gi
./gradlew :generator:installDist

Now there will be a java-gi binary in generator/build/install/java-gi/bin/
Use it like this:

cd ..
mkdir libical-java-bindings
cd libical-java-bindings
../java-gi/generator/build/install/java-gi/bin/java-gi -p /usr/share/gir-1.0/ICalGLib-3.0.gir

The -p parameter will generate a gradle project structure. You can simply run gradle build to build the bindings into a jar file.

The generated sources will have two compile errors that I consider upstream issues. You can easily fix them manually (or remove the offending methods):

1. Timezone.arrayNew() is defined as a constructor in the gir file, but it returns an Array. In my opinion, a constructor should always return an instance of the surrounding class. This method should have been a function in the gir file. Meanwhile, the compile error can easily be fixed by changing the return type etc to Array.
2. Attach.ref() returns void, but it overrides GObject.ref() which returns itself. This kind of overload with a different return type is not allowed in Java. You can fix the compile error by changing the return type and adding a return this; statement.

These kinds of issues are extremely hard to detect by java-gi so for the default set of libraries (GTK etc) I "patch" the gir data to resolve these issues. When generating the bindings yourself from the gir file, you'll have to do this by yourself.

Please let me know if this is a workable solution for you!

[tintou]

Thank you! I'll look at what I can do to fix the issues mentioned. Using the generator dynamically is working great for me!

[jwharm]

I've thought some more about the Timezone.arrayNew() issue. I expect that gobject-introspection exports it as a constructor automatically, so it might be difficult to fix it properly in libical-glib.

Technically, I treat "named" and "unnamed" constructors differently in Java:

• Unnamed constructor foo_new(): a normal new Foo() {} constructor in Java
• Named constructor foo_new_with_bar(): a static method static Foo withBar() {} in Java

For the unnamed constructors, I can't override the return type. Java doesn't allow it. But for a named constructor like i_cal_timezone_array_new I can set the requested return type for the static method. I will change java-gi to handle this.

[jwharm]

I logged a new issue for the constructor return type, closing this one.