Thanks for bringing this up as I’ve been confused by this a few times. Before Polaris I hadn’t really encountered these annotations and I was surprised to learn they don’t “do anything” — that is, there is no additional safety you get at runtime when a null value is passed into a parameter marked non-null. Similarly nothing enforces that you handle null values when something is annotated as nullable.
For that reason, I tend to assume everything is nullable regardless of annotation and I would be in favor of standardizing around that assumption. Iff something is annotated as Non-null a developer should feel safe skipping a check for null, but otherwise they should handle null. I am a big fan of Optional and of trying to reduce the usage of null as much as possible though. On Wed, May 21, 2025 at 3:02 PM 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 >
