Hi Eric, You're right that annotations don't change the bytecode at runtime. Their real value comes during compilation, as many static analysis tools use them to flag potential issues. They can even cause build failures depending on how you configure them. My IDE (IntelliJ) frequently warns me when I forget to handle a potential NPE; if you're not seeing similar feedback, it might be worth checking your IDE settings.
While the annotations are primarily for compile-time checks, that doesn't mean we can't also incorporate runtime checks. We should aim to include these whenever this makes sense, for example by using Guava's Preconditions. This is especially useful if we can't guarantee that a method parameter, for instance, will never be null, because it's being provided by some external system. In my opinion, assuming everything is nullable by default isn't the best approach for writing robust code. I believe a bias towards non-nullness leads to more reliable systems. I am also a big fan of Optional and think we should strive to use it as much as possible. That said, it's not always possible, especially if you are implementing a third-party interface that doesn't use it. Using Optional in class fields and method parameters is also controversial: Optional was designed primarily as a signal from the callee to the caller, to signify: "no result". In other words, its main purpose is to clarify method return types. This post on Stack Overflow by Brian Goetz is worth reading: [1]. Thanks, Alex [1]: https://stackoverflow.com/questions/26327957/should-java-8-getters-return-optional-type/26328555#26328555 On Wed, May 21, 2025 at 4:37 PM Eric Maynard <eric.w.mayn...@gmail.com> wrote: > > 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 > >
