A community for discussion and news relating to JetBrains and its products! https://www.jetbrains.com/
Copyright © 2000-2024 JetBrains s.r.o. JetBrains and the JetBrains logo are registered trademarks of JetBrains s.r.o.
Kicking off afternoon sessions (after sponsors @getsentry and @jetbrains ) at #Laracon is @rissabubbles talking about how D&D can be applied to software dev.
(Should have sent earlier but cell network issues)
@jetbrains Looks like some of your k8s ingresses are presenting self-signed. Lots of workers got this dialog pop up just now.
DMs open
codewithme-lobby.api.jetbrains.comcodewithme-relay-europe-north1-1.api.jetbrains.comcodewithme-relay-europe-north1-2.api.jetbrains.comap-help.api.jetbrains.comoauth2-proxy-api.api.jetbrains.com
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?
