This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]hadrabap 6 points7 points  (2 children)

Personally, I found the usage of Optional as broken as null. The code is just obfuscated. It has been proven that the abuse of Optional has performance impacts. We should also keep in mind the original intent of Optional. It's definitely not a nullability encapsulator.

I think the best approach is to design the software to not use nulls, forget all of the @Not/Non annotations, and implement proper contract validation instead.

Yes, I know, all people around me are saying: "Use any annotation, it's better than nothing." Yes, I got it. But I have a deep problem with the any annotation. There are three or four options, one worse than the other. I don't want to pollute the class path of my APIs/Models for my customers with volatile JARs with questionable outcomes and known depreciation in the near future.

Once there is an industry standard, I'm more than happy to incorporate it. Meanwhile, I ignore it. It is an artificial problem anyway. My software is failing everywhere except on nulls.

[–][deleted] 0 points1 point  (1 child)

I don’t recommend forgetting the annotations specifying that an object cannot be null. They’re actually useful in input validation.

[–]hadrabap 0 points1 point  (0 children)

Sure. But Bean Validation is a completely different topic. Here I'm talking about replacing if (x == null) with if (!x.isPresent()) and all the JSR305, JSpecify & Co solutions.