Explicitly declare nullability of declared API

[xenoterracide]

I wish the package/modules (at least for ddd/event) were "Null marked". @Nullmarked being the annotation provided by https://jspecify.dev. Although I wouldn't care if another JPMS compatible library was used.

Although it should probably have runtime annotations since it seems jakarta-annotation is source only, which doesn't work for spotbugs, and some other things.

not having this will make my replacing some of my own interfaces harder if not impossible.

Note: at this time I don't think... anything really supports just @Nullmarked although some support non null by default and that can be used as a hint.

I'd be willing to put in some legwork here.

[odrotbohm]

As the amount of actual API we introduce is rather low (primarily a few of the interface types in jMolecules DDD) I'd consider this a low priority. Also, the first GA version of jSpecify is pretty young, it still has a few rough edges. There's work anticipated in that area for the next major revision of Spring Framework, favor but also some hesitation expressed in the interview with Jürgen here:

From the Spring side, we need official meta-annotation support so that we can declare our own nullability annotations with JSpecify meta-annotations instead of JSR 305 meta-annotations.

I'm not saying we need to adhere to Spring Framework, but describing the lack of usage of such annotations as “making something impossible” is a bit of a stretch, as virtually none of the Java world already work with them.

[xenoterracide]

there are alternatives that aren't jspecify. It's just one such set of annotations.

as virtually none of the Java world already work with them.

actually almost all of the java world works with them, just not according to spec. Rather you have to do the opposite of what they want an annotate all the things. Almost all of the java world just looks at the stringy name now, instead of relying on a pure list of annotations. That said, I'm not beholden to those, I don't much care, I'd just like to use something (that's not javax due to jpms).

I'd consider this a low priority

Fair, but I did offer to put in the effort.

[odrotbohm]

Twisting my and your own words is not gonna get us any further. You explicitly mentioned jSpecify and I replied to that. I don't have anything to add what I wrote above: we hardly define any methods that would benefit from us deciding about the nullability constraints of those.

I am happy to revisit the places we already have actual assertions in place. That said, you can interpret the absence of nullabilty annotations an indicator of us currently not taking a stance on exactly that fact.

[xenoterracide]

Although I wouldn't care if another JPMS compatible library was used.

I also said that. I think you are trying to twist my words.

That said, you can interpret the absence of nullabilty annotations an indicator of us currently not taking a stance on exactly that fact.

yeah, but that's not how existing tooling works with that. I might read it that way, but tooling doesn't ensure any safety in that case and can provide a variety of assumptions.

[xenoterracide]

just an FYI, looks like spring is moving to jspecify spring-projects/spring-framework#28797 (comment)

[odrotbohm]

You've read it here first, two weeks ago.

There's work anticipated in that area for the next major revision of Spring Framework …

[xenoterracide]

Fair enough although you'll see that that ticket has some back and forth. The last I'd heard it was anticipated but they weren't going through with it yet because 1.0 didn't offer what they were looking for. I couldn't be sure you weren't working off of the information I had prior to that. which has been "they said they were", "they said they weren't". now they said they were again.

[odrotbohm]

To summarize a team call we just had:

• We consider the introduction of jSpecify annotations to define the nullability of API exposed by jMolecules, in particular the DDD artifact.
• The only API affected is
  • Identifiable.getId()
  • Association.forAggregate(…)
  • Association.forId(…)
• Declaring Identifiable.getId() as non-nullable might be a breaking change for projects that use persistence mechanisms that support persisting a domain model directly and also use database generated identifiers at the same time. While especially the latter doesn't fit well the notion of modeling an aggregate, we have to evaluate the impact. Generally speaking, we feel we favor the move.

I've started polls on Mastodon, LinkedIn, and Bluesky to get further input.

[xenoterracide]

Identifiable.getId() I'm fine with this being @Nullable, I believe that overriding it with @NonNull would change that if someone wanted to... although there's also

implements Identifiable<@Nullable Long> { }

which could also be suggested? but is not well supported by tooling yet (AFAIK)