> > 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 agreed with the intention, but am concerned that assuming everything is non-nullness may discourage null-checking, which is problematic as runtime null-checking isn't a thing. Yufei On Wed, May 21, 2025 at 9:52 AM Alex Dutra <alex.du...@dremio.com.invalid> wrote: > 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 > > > >
