????
Where is autoboxing?
Java 25 (preview)
#autoboxing error
sage ledge
round canyonBOT
<@&987246399047479336> please have a look, thanks.
dawn crane
what type is the local temperature exactly?
tidal cobalt
maybe it could be because of the annotation on temperature?
anyways for now as a workaround just cast it because this is unusual
atleast for me
hardy cloak
maybe it could be because of the annotation on temperature?
Yeah that is strange. I don't think it's a Java error I think it's an IntelliJ error
Basically when you have a nullable Double you might not be able to turn that into a double
Because the lowercase version which is the primitive cannot be null
So the type checking is actually correct
You need to assert that you do not have a null Double
Sorry respond to the wrong person
You can think of @Nullable as being a hook that people use to extend Javas type system
desert pawn
????
Where is autoboxing?
Java 25 (preview)
show the whole code please
lunar fog
Yeah that is strange. I don't think it's a Java error I think it's an IntelliJ e...
I think you are right. I had this very same thing a couple months ago using JSpecify. I don't remember how it was resolved. I think I even tried lookign at their bug database but for something like this, nearly impossible to find in all the noise.
```
IntelliJ IDEA 2025.2 (Ultimate Edition)
Build #IU-252.23892.409, built on July 31, 2025
Source revision: 0a9a69b3f9332
I don't think it's a bug. This is correct behavior when you have nullability in the typesystem
hollow leaf
An autobox should always be considered not-null (vs a reference being unboxed which must be shown to be not-null).
Assigning a non-nullable value (the boxing of double) to an assignable and nullable Double reference should be legal.
lunar fog
Intellij has their own @Nullable annotation. Maybe it's confused.
vast jacinth
@sage ledge can you share the whole code, including the imports used?
sage ledge
Sorry for the delay
Just saw it now
Let me share
lines 1196 and 1210
Maybe an IntelliJ problem. I did nothing and it's gone
vast jacinth
i think using optional should work
```
private Optional<Double> temperature = Optional.empty();
public @NonNull Builder temperature(double temperature) {
if (temperature < 0.0 || temperature > 2.0) {
throw new IllegalArgumentException("temperature must be between 0.0 and 2.0");
}
this.temperature = Optional.of(temperature);
return this;
}
Detected code, here are some useful tools:
hardy cloak
Wait this is lobotomy inducing
sage ledge
Is it a good practice to use optional in instance variables? Someone told me they just use it in method return types
hardy cloak
The error is that you didn't handle a possible null
IntelliJ was 100% correct to give you an error for that as part of their static analysis
You don't need to engage optional at all here. Yeah generally just use it in return types
You're not going to explode if you use it as a field, but treating it as a solution to this is going to drive me crazy
hollow leaf
this can't be null, the parameter temperature parameter (a double) can't be null, and the autoboxing of temperature can't be null.
Where is it possible to be null? The checker framework has a bug - it seems to be conflating the risks of unboxing with boxing.
dawn crane
oh it's using checker framework
hardy cloak
`this` can't be null, the parameter `temperature` parameter (a double) can't be ...
Am I reading it backwards then? Well regardless no reason to pop out optional
lunar fog
`this` can't be null, the parameter `temperature` parameter (a double) can't be ...
If it was confusing unboxing/boxing then the suggestion would probably be different instead of asking to cast. This is an intellij suggestion I thought. I don't know if that system integrates third party checkers. Also JSpecify is involved which was same thing I was using when I hit this "bug".
My gut say this is still intellij, confused that it's using it's own jetbrains nullable annotations for some reason with my best guess being telemetry reasons.