Should @DefaultNullable even exist, given it's probably not that recommendable? about jspecify HOT 10 CLOSED

Also, do we need @DefaultUnknown? That will be the default if no default annotation is provided, so I'm not sure why people would need to use it.

from jspecify.

The use case for that is that you're able to bring 90% of a class up to date but one or two methods are giving you trouble (you can't figure out how to annotate them correctly or it will cause too much pain to do it yet). Or, if we support package or module annotation, and there's one or two classes you're not ready to deal with yet. We have a strong interest in those users being able to flip their default (so it catches new code) even when they're not ready to address those edge cases yet.

from jspecify.

I don't know of use cases for @DefaultNullable, it can be added when we find any. There's a precedent: Eclipse doesn't have nullable default while having a non-null one: https://help.eclipse.org/mars/index.jsp?topic=%2Forg.eclipse.jdt.doc.isv%2Freference%2Fapi%2Forg%2Feclipse%2Fjdt%2Fannotation%2Fpackage-summary.html

from jspecify.

The current decision as documented in the draft spec is to provide all six annotations for conceptual simplicity and parallel structure. I personally think this is a fine decision and haven't heard strong opposition to it. Optimistically closing so it's easier for us to focus on the more pressing issues.

from jspecify.

I might be strongly opposed. But I'd have to think about it more: I've been pretty much assuming that we're leaving @DefaultNullable out. And that has simplified the number of cases and interactions we need to analyze. In other words, the very fact that I haven't had to think about this more is itself a giant benefit IMO.

from jspecify.

Thinking about this more, I think there's a decent chance that people will autocomplete @DefaultNullable accidentally (over @DefaultNotNull) often enough that that alone may make it provide net negative value.

But beyond that, I think this ties into many of the same issues as including @NotNull does (like in this post). For both philosophical and technical reasons, I think that @DefaultNullable and @NotNull should probably live or die together. I'll include some points about @DefaultNullable when I make my last stand on @NotNull :)

from jspecify.

It's been occurring to me more and more lately that it would be much easier for users to read code and understand nullness information correctly if they knew there were ONLY TWO possibilities: this is a file that's "in the club" (default not null applies) or this is a file that's "not in the club" (default nullness unspecified applies).

So I am starting to understand the advantage of ditching @DefaultNullable in a way I strangely wasn't before.

from jspecify.

Oh, and also: if this ever one day becomes a Java language feature, I would almost guarantee that that's how it would work: a file would either be modernized or legacy, no other possibility.

from jspecify.

How are people feeling nowadays about optimistically closing this issue and operating under the assumption that we'll leave @DefaultNullable out?

from jspecify.

imho it would be very useful to do this. It will simplify our work to figure out things like defaults for type parameter bounds. Then if we want to propose reintroducing it in the future, we will have to fully consider how it interacts with all our prior decisions, but that is fine with me.

from jspecify.