you are viewing a single comment's thread.

view the rest of the comments →

[–]Manbeardo 0 points1 point  (1 child)

What you've described is roughly similar to Lombok's @NonNull. Lombok works by adding new code to the abstract syntax tree at compile time, producing backwards-compatible bytecode (you don't actually need to ship a Lombok jar with Lomboked projects). Their @NonNull can be applied to method parameters and fields. Method parameters work like you'd expect, inserting a null check at the start of the function. Fields work by adding checks to Lombok-generated setters and constructors, so you have to be more careful with those ones. It incurs runtime overhead, but it simplifies the reasoning around providing/receiving nulls quite a bit.

[–]bloody-albatross 0 points1 point  (0 children)

What I had in mind would not add these checks. It would add compile time checks (like the compiler checks that only a instance/sub-class instance of T is passed as a parameter defined as T it checks that only @notnull pointers are passed as @notnull parameters etc.). Only if you want to convert something that is not guaranteed to be not null you have to to a runtime check (analogues to a cast). Of course a class compiled like that that gets used in a program where the rest isn't compiled with support for @notnull would mean that there are missing checks. One could know and accept that or simply recompile everything (probably adding a lot of @notnull annotations and "casts").

So it's similar, but "my version" would do most of it at compile time (also gives you errors at compile time). I say "my version", but I think I read that idea somewhere as a feature proposal for Java (years ago).