Nullable/NotNull hinting with smallrye-common annotations

[heubeck]

Hey dear Mutiny maintainers @jponge and @cescoffier,

sorry for not showing up for so long... hoping and trying to restart contribution activities in autumn with a new Quarkus/Kotlin/Mutiny project.

Coming from #901:
I'm wondering, if - and which - Nullable/NotNull annotations could be used for hinting the Mutiny API.
Major objective would be to add the used annnotations to the Kotlin compiler for getting first-class null-type safety.

There are Nullable/NotNull annotations available from smallrye-common-constraint, but Mutiny is not dependent on common-constraint yet, cannot rate if this is an option, WDYT?

Mutiny holds a dependency to smallrye-common-annotation though, which feels more lightweight than common-constraint (because of less 3rd party dependencies).

WDYT?
My first impulse (in a non-public project) would be to move Nullable/NotNull from common-constraint to common-annotations, do you thing this is an option in the smallrye-common lifecycle? (Add new annotations, deprecate the old ones, switch to new ones with next major version.)
Other ideas, or maybe complete denial of nullable type hinting at all?

Thanks and read you soon
Florian

[jponge]

Hi @heubeck!

I'm not in favor of adding another library dependency. I know smallrye-common-constraint is very lightweight, but it's still an extra dependency for a single annotation.

So one option could be to have the annotations from this library being moved to smallrye-common-annotation, but that's likely to be a breaking change for other projects. /cc @radcortez

Now I suspect that the Kotlin compiler might look for @Nullable / @NotNull annotations no matter the package name, perhaps like @CheckReturnValue that's used by IntelliJ IDEA to hint at bad API usages. Do you have more insights what the compiler wants?

I fully understand the use-case (Kotlin expects Java types to be nullable by default and that can be an annoyance), but I want to limit the impact as much as possible.

[jponge]

It would unfortunately still be a problem because Kotlin has hard-coded constants and we'd need them to endorse ours.

Adopting JSpecify would probably be a better option (but it's still yet another library)

[jponge]

...yet according to https://github.com/jspecify/jspecify:

The latest release is numbered 0.2 as a clear signal to not depend on it yet. It will still undergo many changes.

Not a very good signal.

[heubeck]

And it's not recommended to be adopted yet, as still under specification, as I understood.
So maybe postpone this til some maturity is reached?

[Ladicek]

Just FYI, Jakarta EE 10, or specifically Jakarta Common Annotations 2.1, added their own Nullable and Nonnull :-)

[jponge]

And it's not recommended to be adopted yet, as still under specification, as I understood. So maybe postpone this til some maturity is reached?

Yes