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 >
