Generally I agree on the proposal as well. Although I admit that I'm on
the fence there - neither pro nor con.
What I think would be quite useful is that the IDE respects the
non-null-default - not sure how good jspecify's @NullMarked/NullUnmarked
is being supported nowadays. There was another one in jsr305 - but
jsr305 is history nowadays. IIRC it didn't work for Java modules a while
back, useful to only specify that annotation once for a whole module and
not for every package.
WRT REST, I think we can get away with jakarta-validation.
Also agree that Optional is generally fine and the preferred way. There
can be legit exceptions though.
On 22.05.25 18:12, Dmitri Bourlatchkov wrote:
I agree with what Alex proposed (quoted below).
Re: "assuming non-null by default". I believe this was intended in the
spirit of
code annotations, meaning that we need not use @Nonnull everywhere.
I do not think this was intended to mean that code does not have to check
that the value is not null if there's reason to believe it might be.
That said, I think it makes sense to use @Nullable to indicate values that
can be null during normal execution.
I'd propose to use @Nonnull only to remove uncertainty (this should rarely
be needed).
As for null checks, I think it makes sense to perform them when parameters
are accepted from users or external calls (REST API, config), but otherwise
code can propagate values normally. If the value is nullable use @Nullable
otherwise no annotation is needed.
Re: Optional: My take is that it makes flowable coding easier (.map()
instead of `if`), so I think it is fine to use it both in parameter and
return
values. I do not think we need to "force" its usage, though.
Cheers,
Dmitri.
On Wed, May 21, 2025 at 10:02 AM Alex Dutra <alex.du...@dremio.com.invalid>
wrote:
Hi all,
A while ago, we had a discussion regarding which nullness annotations
to use and whether we should consider favoring non-null by default. I
would like to revive that discussion.
We are currently using the `jakarta.annotation` package consistently,
but the defaults are not clear: should we consider everything as
non-null by default and only annotate the nullable things, or the
other way around? Some classes are cluttered with both annotations,
which seems unnecessary and confusing.
I would personally be in favor of considering everything as non-null by
default.
Please let me know your thoughts.
Alex
--
Robert Stupp
@snazy
