I'd say they are interesting for documentation, I think an annotation is way more explicit than an obscure sentence in the Javadoc.
With a good IDE integration you get warnings/errors "at design time", true it's not checked by the compiler but it still points out potential issues.
I don't have to deal with null checks since they are automatically generated.
It's clearly not ground breaking but I wouldn't say useless 🙂
Thanks for the pointer, Optional (or similar constructs) are indeed a safer solution, at least for return types.
For method parameters I don't think they really provide any additional safety: you basically have to check if the provided Optional is null. It would be nice to have auto boxing of null into Optional, but as far as I know it's not the case (and I guess there are good reasons for that).
As mentioned in the article, this is a convention. To make it work it's enough to get rid of all explicit null values in code. This condition is much easier to check (search over all code). From my experience I can tell that not using null in code is an easy to get used to quite quickly.
With this convention nulls may appear only from external libs/code, but habit to create safety wrappers for such code also grows quickly. There is also similar approach to handling errors without using exceptions. Together these approaches result to concise, expressive and safe code, which is easy to write, read, test and maintain.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I'd say they are interesting for documentation, I think an annotation is way more explicit than an obscure sentence in the Javadoc.
With a good IDE integration you get warnings/errors "at design time", true it's not checked by the compiler but it still points out potential issues.
I don't have to deal with null checks since they are automatically generated.
It's clearly not ground breaking but I wouldn't say useless 🙂
It's somewhat worse than useless, since it may give false feeling of safety. There is an alternative approach described here.
Thanks for the pointer, Optional (or similar constructs) are indeed a safer solution, at least for return types.
For method parameters I don't think they really provide any additional safety: you basically have to check if the provided Optional is null. It would be nice to have auto boxing of null into Optional, but as far as I know it's not the case (and I guess there are good reasons for that).
As mentioned in the article, this is a convention. To make it work it's enough to get rid of all explicit null values in code. This condition is much easier to check (search over all code). From my experience I can tell that not using null in code is an easy to get used to quite quickly.
With this convention nulls may appear only from external libs/code, but habit to create safety wrappers for such code also grows quickly. There is also similar approach to handling errors without using exceptions. Together these approaches result to concise, expressive and safe code, which is easy to write, read, test and maintain.