The future of the GStreamer Java bindings?

[Neil C Smith]

Hi Sebastian,

Thanks for your thoughts here ..

On Sat, 25 Feb 2023 at 16:24, Sebastian Dröge via gstreamer-devel
<gstreamer-devel at lists.freedesktop.org> wrote:
> I don't think anybody of the GStreamer developers has enough knowledge about Java/JNA/Panama either to take over maintenance of the bindings.

Yes, it needs people with a good knowledge of both GStreamer, and of
the JVM and its native interoperation.  I started this thread more
with the thought that there might be people on this list but outside
of the core GStreamer developers with an interest in the bindings
continuing.

To be clear, I'm not necessarily looking for someone to take over
maintenance - just share investment in it one way or another.

And also, I'm certainly going to continue working with GStreamer on
the JVM too, as I'm using it in some other personal and company
projects.  However, over the years I've developed a number of bespoke
bindings for clients, who for one reason or another didn't want to use
gst1-java-core.  I'll likely switch those projects to a similar model,
rather than carry on maintaining a general purpose library with a lot
of features we don't use.

> That (AFAIU) the bindings are completely manually written instead of making use of code generation based on the gobject-introspection data is not helping much either to keep the effort required for maintenance low.

Yes, we had a good chat about that in Edinburgh rather a while ago
now! :-)  Using the introspection data for the lowlevel bindings is
certainly doable, and I actually spent a little time on this again not
that long ago.  However, using them to generate the higher level API
that people use, while keeping it (mostly) compatible, would be more
difficult.

The bindings also map GObject and Java object identities and
lifecycles, in a way that makes them easier to use, but also makes
generation more difficult.  As well as providing an additional source
of issues.

> FWIW, there's another set of Java bindings which are mostly autogenerated: https://github.com/jwharm/java-gi
> I personally didn't try those and as they're quite new I expect a few issues to be found once people start using them, but at least they're actively developed and maybe something more future-proof.

Thanks for that link!  That's really interesting, and I may just ditch
the introspection code I had. :-)  One stumbling block with
auto-generation of the bindings was the need to also handle GLib and
GObject - the old JGir project https://wiki.gnome.org/Projects/JGIR
actually used code from the original GStreamer Java bindings that I'd
already fixed the memory leaks in, so was a non-starter.

There's also some old code by Roland Elek in our GitHub organisation -
https://github.com/gstreamer-java/gir2java  That never became fully
usable (and is why gst1-java-core came about).  Hopefully those new
bindings can do better, and targeting Panama (new Java FFI) is good,
although that's still not out of preview status so also going to be a
constraint on using them for some time.

Thanks and best wishes,

Neil

-- 
Neil C Smith
Codelerity Ltd.
www.codelerity.com

Codelerity Ltd. is a company registered in England and Wales
Registered company number : 12063669
Registered office address : Office 4 219 Kensington High Street,
Kensington, London, England, W8 6BD