Annotations are, unfortunately, all over the board. There's a dozen different `NotNull` annotations out there. Having it in the language will make it the last solution to this problem.
You can't do deduction at compile time because you'll end up with different method signatures if someone calls a method with a null vs not. (not to mention the problem with someone calling these methods with reflection)
You can do deduction at runtime (and they likely will), but then you have to deal with the problem of unwinding an optimization when the hypothesis is proven wrong. That can be really costly when the optimization is dealing with memory layout. (Imagine an array of value types where you deduced they should be non-null, yet some unexpected path inserts a null. In that case you have to reallocate the entire array and it's elements in order to handle that).
It's more than just syntactic sugar.
So `Point p = null` won’t type check, you would have to mark it as `Point?` where Point is a value (primitive) class. There were also points that it should work with the usual type inference, e.g. `final var p = methodThatReturnsNullablePoint()` would be inferred to `Point?`.
String! myString = “Definitely not null”;
Edit: it’s worth saying that a lot of careful thought around compatibility goes into features like this. That means the core libraries should be able to transition to non-billable types where this is already a run time requirement, and existing compiled jars must continue to work.
So now we are back at warnings if non nullable references are enabled on the compiler settings, and eventually we can turn them into warnings as errors.
The biggest issue is the large ecosystem of existing libraries.
`MyClass! myvar` is not supposed to accept nulls. Assigning null to `myvar` would throw exception, comparing `myvar` with null is pointless and probably should emit a warning. Or maybe even error.
`MyClass? myvar` is supposed to accept nulls. Dereferencing this value without checking for null is either warning or error.
`MyClass myvar` is supposed to be unspecified with regards to nulls. So basically current code. You can do whatever you want but you should refactor it to `MyClass!` or `MyClass?` some day.
Although perhaps they could resolve this with magic imports?
import java.lang.magic.optional;
public class Foo{
public static void main(String...args){
Foo? f = ...;
if(f){
f.doThings();
}
f.doThings(); //compile time error
}
}
It would be like a variant of inviting Dracula across the doorposts, only that this one may or may not actually be a cool guy and not a vampire, but in any case he will sure bring all his friends, and their friends and so on forever.
There are already lots of techniques, from annotations to Optional.ofNullable but none matches the simplicity of != null.
They can also go the route of `effectively final` and make the compiler deduce nullness instead of marking it explicitly.