Library publicity

mrlem commented

2025-06-08 18:23:20 +02:00

(Migrated from github.com)

It took me some time to stumble on Java GI (I did so indirectly), don't you think the library could have its entry in GTK bindings list now?

I found this 2022 gnome discourse discussion where you mentioned you wanted the lib to be more mature before this happens, and was wondering what your thoughts were now. I personally think the binding is very decent and completely apt to produce nice apps, and it would gain from a broader audience, which this list could bring (as that's the natural place to check for a way to create gnome apps using Java).

It took me some time to stumble on Java GI (I did so indirectly), don't you think the library could have its entry in [GTK bindings list](https://www.gtk.org/docs/language-bindings/) now? I found this 2022 gnome discourse [discussion](https://discourse.gnome.org/t/new-java-bindings-feedback-appreciated/12490) where you mentioned you wanted the lib to be more mature before this happens, and was wondering what your thoughts were now. I personally think the binding is very decent and completely apt to produce nice apps, and it would gain from a broader audience, which this list could bring (as that's the natural place to check for a way to create gnome apps using Java).

jwharm commented

2025-06-08 21:39:06 +02:00

(Migrated from github.com)

Thank you for your interest in java-gi and for the kind words!

I know about the GTK website.
And there's a similar page on the GNOME website.

Personally I want to finish a few more backlog items before I consider the library stable enough to recommend it more widely:

Now that I registered java-gi.org, I want to move everything from io.github.jwharm.javagi to org.javagi (maven coordinates, module and package names) but this is a breaking change for existing users, so I want to first publish a smaller 0.12.3 release with bugfixes and small enhancements, and only use the new domain from 0.13.0 onwards.
I want to implement a decent regression test suite, using gobject-introspection-tests. I started working on this a little while ago.
I'd like to use JSpecify nullability annotations instead of Jetbrains Annotations. This might be a breaking change for some users (I'm not sure yet).
I want to extend the "HelloTemplate" example, to be a complete Flatpak application with icons, translations, resources, settings, a .desktop and a metainfo.xml file. This is relatively easy to do with a Meson build script. (Meson would still execute Gradle as a custom build step to compile the application.)

Now, this list used to be a lot longer 😄 so it's probably just a few months more, before I'd say it's "good enough". But it's a weekend/evening project, so I can't make any promises. If there's anything you'd like to contribute, let me know!

Thank you for your interest in java-gi and for the kind words! I know about the GTK website. And there's a [similar page](https://developer.gnome.org/documentation/introduction/languages.html) on the GNOME website. Personally I want to finish a few more backlog items before I consider the library stable enough to recommend it more widely: - Now that I registered java-gi.org, I want to move everything from `io.github.jwharm.javagi` to `org.javagi` (maven coordinates, module and package names) but this is a breaking change for existing users, so I want to first publish a smaller 0.12.3 release with bugfixes and small enhancements, and only use the new domain from 0.13.0 onwards. - I want to implement a decent regression test suite, using [gobject-introspection-tests](https://gitlab.gnome.org/GNOME/gobject-introspection-tests/). I started working on this a little while ago. - I'd like to use JSpecify nullability annotations instead of Jetbrains Annotations. This might be a breaking change for some users (I'm not sure yet). - I want to extend the "HelloTemplate" example, to be a complete Flatpak application with icons, translations, resources, settings, a .desktop and a metainfo.xml file. This is relatively easy to do with a Meson build script. (Meson would still execute Gradle as a custom build step to compile the application.) Now, this list used to be a lot longer 😄 so it's probably just a few months more, before I'd say it's "good enough". But it's a weekend/evening project, so I can't make any promises. If there's anything you'd like to contribute, let me know!

❤️ 3

mrlem commented

2025-06-09 10:12:58 +02:00

(Migrated from github.com)

Thanks for the insights, all those points seem indeed valuable.
I'll try to help. For instance, I can look into the JSpecify annotations migration (and at least see whether it causes errors / warnings in the existing examples & my own pet project).

Thanks for the insights, all those points seem indeed valuable. I'll try to help. For instance, I can look into the JSpecify annotations migration (and at least see whether it causes errors / warnings in the existing examples & my own pet project).

jwharm commented

2025-06-11 08:14:56 +02:00

(Migrated from github.com)

That'd be appreciated!

The nullability annotations are currently only set on parameters, not return values. And array elements and generic types aren't annotated yet. The current code is very simple:

With JSpecify, we can annotate the entire class @NullMarked (which means everything is default not-null), and add @Nullable where applicable.

That'd be appreciated! The nullability annotations are currently only set on parameters, not return values. And array elements and generic types aren't annotated yet. The current code is very simple: * [CallableGenerator.generateMethodParameters](https://github.com/jwharm/java-gi/blob/main/generator/src/main/java/io/github/jwharm/javagi/generators/CallableGenerator.java#L131-L134) * [Parameter.nullable/notNull](https://github.com/jwharm/java-gi/blob/main/generator/src/main/java/io/github/jwharm/javagi/gir/Parameter.java#L136-L146) With JSpecify, we can annotate the entire class `@NullMarked` (which means everything is default not-null), and add `@Nullable` where applicable.

jwharm commented

2025-06-14 13:48:22 +02:00

(Migrated from github.com)

@mrlem I have a rather large PR (#238) ready to merge into main, changing the packages and modules from io.github.jwharm.javagi to org.javagi. If you're working on a PR for JSpecify annotations, I can wait with merging until you're ready? Because #238 moves all source files around and will make merging other changes a hassle.

@mrlem I have a rather large PR (#238) ready to merge into main, changing the packages and modules from `io.github.jwharm.javagi` to `org.javagi`. If you're working on a PR for JSpecify annotations, I can wait with merging until you're ready? Because #238 moves all source files around and will make merging other changes a hassle.

mrlem commented

2025-06-14 15:38:41 +02:00

(Migrated from github.com)

@jwharm don't wait for me, go for it. I'll rebase what I have done (didn't have as much time as I wanted this week, and won't have much more time this week-end)

👍 1

jwharm commented

2025-10-18 14:54:07 +02:00

(Migrated from github.com)

Hey @mrlem are you still looking into the JSpecify nullability annotations? Otherwise I'll probably give it a go by myself.