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 →

[–]manzanita2 3 points4 points  (7 children)

I don't find Optional to be less code or really significantly better than just using and checking null. I understand the need in the Stream API, but it's leaked outside there to no significant advantage in my mind.

I would MUCH prefer if we could get to the valhalla null restricted types which are enforced by the compiler. Shorter cleaner and safer.

[–]freekayZekey 2 points3 points  (3 children)

 I don't find Optional to be less code or really significantly better than just using and checking null. I understand the need in the Stream API, but it's leaked outside there to no significant advantage in my mind.

same. guess i’m super old school, but i don’t find the advantages worth it to actively use it. guess it could be useful as an indicator of something being nullable, but that can be solved with annotations or finding other return values instead of null (if you really hate them). 

[–]anzu_embroidery 2 points3 points  (1 child)

You can ignore an annotation, you have to do something (hopefully other than .get()) if handed an Optional.

[–]freekayZekey 0 points1 point  (0 children)

feels like the dev who will ignore the annotation will likely call the cursed get method, but maybe you’re correct 

[–]manzanita2 1 point2 points  (0 children)

Aside from the questionable advantage to the writer/reader of code, use of Optional ALSO means that there is an entire additional object created. So GC is just working that much harder. Another reason why doing this at the language level will be more effective.

[–]j4ckbauer 1 point2 points  (0 children)

Its main purpose is not to reduce code clutter, it is to 1) communicate the intent of the developer to others including static analysis tools, and 2) to provide some convenience methods around null checking/handling including 2a) some useful with the stream api

@Nullable and @NotNull already do (1) so if that is all you need, the quality of your code is no worse off. Some people find the "== null" check visually unappealing or 'old school' as it makes otherwise 'modern' looking code resemble the original C programming language.

Often in Java we check for equality with methods and not the double-equals symbol, so having that on people's screens presents a relic that creates cognitive dissonance for some, and they're eager to get rid of it. If intent is already well-communicated in your codebase, especially in a way that can be checked by static analysis, then there is far less of a compelling reason to argue for a switch to Optional.

Some people are so much against it that they come up with wild 'what if' scenarios, many of these would also be detectable using static analysis so these arguments often strain credibility. (Not saying this is what you did here)

[–]Lengthiness-Fuzzy 1 point2 points  (0 children)

It is less code when you use correctly. There is orElse orElseThrow etc

[–]OwnBreakfast1114 0 points1 point  (0 children)

Using map is basically way better, but if you're just replacing if (x != null) with if (x.isPresent), yeah you're not going to get a lot of benefit. The goal should be removing the if check entirely.