this post was submitted on 13 Aug 2024
2 points (66.7% liked)

JetBrains

166 readers
1 users here now

A community for discussion and news relating to JetBrains and its products! https://www.jetbrains.com/

Related Communities

Copyright © 2000-2024 JetBrains s.r.o. JetBrains and the JetBrains logo are registered trademarks of JetBrains s.r.o.

founded 9 months ago
MODERATORS
 

Link to a (frustratingly) deleted question on Stack Overflow. Text and image copied below incase you don't have the ability to see it. (Not sure why the image shows multiple times.)


Is there any way to more granularly control IntelliJ IDEA's inspections' "Nullability and data flow problems" option "Treat non-annotated members and parameters as @Nullable"? Preferably for unboxing specifically?

I am aware I can use a variety of @Nullable annotations in a variety of places in the code to make the warnings appear. That's not always an option as the place the boxed primitives are coming from may be other libraries you don't have control over. (Imagine if the Holder record below was from a different project.) I included other examples below to illustrate my point.

public class Sample {

    private final Boolean value;

    public Sample(Boolean value) {
        this.value = value;
    }

    private boolean isValue() {
        return value; // I would like a warning here
    }

    private static Boolean boxedTrue() {
        return true;
    }

    private static boolean unboxedTrue() {
        return boxedTrue(); // No warning here, but that's understandable since never null
    }

    private static Boolean boxedNull() {
        return null;
    }
    
    private static boolean unboxedNull() {
        return boxedNull(); // Only warning in the file (by default)
        // "Unboxing of 'boxedNull()' may produce 'NullPointerException'
    }

    public record Holder(Boolean value) {}

    public boolean openHolder(Holder holder) {
        return holder.value(); // I would like a warning here
    }
}

When "Treat non-annotated members and parameters as @Nullable" is enabled, the following gives warnings. While that makes sense given the name of the option, there is code like this literally everywhere. It adds hundreds of warnings to my project. I'm trying to find more granular choices.

    public static ZonedDateTime timeStuff(LocalDateTime localDateTime, ZoneId zoneId) {
        return localDateTime.atZone(zoneId); // I do not want warnings for this
    }

I see that the Java Class Library has JetBrains annotations despite not actually being annotated. Is there perhaps some way to add these automatically to libraries if there is no better way to control the inspection?

Showing @NotNull and @Contract annotations on LocalDateTime.atZone(ZoneId)

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] 1 points 3 months ago* (last edited 3 months ago)

What I'm trying to get is warnings for unboxing things that are of an undefined nullity (i.e. not explicitly nullable or non null) (whether or not that comes from inferring) and storing them in primitive values, but not get warnings for all unchecked usages of undefined nullity.

I believe the issue I originally encountered was because I was working with some DTOs that were using boxed values to make them optional. While it's true that this is an undefined nullity just like 99% of other code, I believe this use case specifically is so common that I'd like to see warnings for potentially null boxed values like Integer and Boolean.