Let's clarify what we talk about when we say "presumed" about non-annotated
arguments - my opinion below.
>From my POV, for human developers presuming @Nonnull would be natural. I
certainly do that (unless javadoc is explicit). The "natural" aspect, IMHO,
comes from the fact that returning a value
> And those arguments are currently presumed nullable?
I would rather say that the current state of the code is "undetermined
nullness".
Just one random example: PolarisCatalogHelpers [1]. This class has no
nullability annotations, yet all of the parameters without exception
are implicitly non-nu
Hi all,
> So now, the onus is on me, as the developer to write [...]
But this remark is valid both ways, right? If the default is non-null
and my method can return null, the onus is on me to annotate it with
@Nullable; but if the default is nullable and my method cannot return
null, then the onus
I think frequency is a hugely important goal, behind perhaps only accuracy
(if I see an annotation or a lack of one, can I trust it?).
The largest group of parameters we currently have is certainly
non-annotated arguments, no? And those arguments are currently presumed
nullable?
--EM
On Mon, Jun
The thing is that IntelliJ, for example, does not infer @Nullable very well.
For example:
Map m = new HashMap<>();
private @Nullable String value() {
return m.get("key");
}
private void test() {
String value = value();
if (value.length() > 3) {
m.put("key", value);
The concern, for me, is whether the onus is on the developer or on the
tools. For example, if I write a method:
public String getTheValue() { return map.get("value");}
with no annotation, the assumption is the return value of getTheValue is
always non-null even though java.util.Map does not make
If we've checked something is non-null or received a non-null value from a
library, we can continue annotating it as @Nonnull within Polaris. We can
also use Optional to get similar functionality to typescript's ? and handle
missing values that way.
In all other cases, developers must assume any g
Right, but I think Michael is correct that when something comes from
outside of Polaris, we have to assume it’s nullable even if it’s not
annotated as such.
Also as we are using CDI, it may not be clear whether an implementation of
an interface is coming from “Polaris code” and therefore what assu
Yes, the idea is to simplify things by using only one of @Nullable
and @Nonnull in Polaris code.
However, I lean toward using @Nullable when necessary and assume @Nonnull by
default. Again this is only for Polaris code.
Cheers,
Dmitri.
On Tue, May 27, 2025 at 5:07 PM Eric Maynard
wrote:
> If w
Your example is quite valid, Mike. In my proposal (several emails ago) I'd
classify this as "inputs into Polaris code".
However, I guess the topic of this thread is slightly different. The
question we're trying to reach consensus on, is about what we should
annotate as @Nullable in Polaris code.
I generally assume the other way around. Many (most) libraries don't
annotate the return values of their methods, so I assume everything is
nullable unless specifically told otherwise. I would prefer everything be
non-nullable unless specifically stated (the ? is the one thing I would
steal from ty
Hi,
My proposal was centered around compile-time checks and targets mostly
developers and contributors. I am not questioning the usefulness of
runtime checks when these make sense.
Maybe an example is better than a thousand words. Let's imagine a
simple getOrDefault() method. Which version do you
My preference is for option 1 below.
On Thu, May 22, 2025 at 1:53 PM Alex Dutra
wrote:
> Hi,
>
> My proposal was centered around compile-time checks and targets mostly
> developers and contributors. I am not questioning the usefulness of
> runtime checks when these make sense.
>
> Maybe an examp
Generally I agree on the proposal as well. Although I admit that I'm on
the fence there - neither pro nor con.
What I think would be quite useful is that the IDE respects the
non-null-default - not sure how good jspecify's @NullMarked/NullUnmarked
is being supported nowadays. There was another
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
>
> 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-checki
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 whe
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
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
19 matches
Mail list logo
