Win a copy of Testing JavaScript Applications this week in the HTML Pages with CSS and JavaScript forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Bear Bibeault
  • Ron McLeod
  • Jeanne Boyarsky
  • Paul Clapham
  • Tim Cooke
  • Liutauras Vilda
  • Junilu Lacar
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • fred rosenberger
  • salvin francis
  • Piet Souris
  • Frits Walraven
  • Carey Brown

About Optional<T> and its usage

Posts: 1268
IBM DB2 Netbeans IDE Spring Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Maybe I didn't fully understand the value of this new feature, but honestly I'm having hard times to figure out how and when to use it.
I created a simple class, Item:

and a trivial class, OptionalUsage, to play with Optional:

In Optional class, I coded two very simple methods, to find a given Item in a collection (Ok ok : with Streams,  I won't need to write such methods by hand anymore; assume mine as a toy class).
With respect to input parameters, my feeling is that it would be generally speaking better to continue to use "plain" parameters, i.e. without using Optional<T> at all, and let method code to use Optional as "syntactic sugar"  to handle potential null references.
In my example, I preferred old style null checking; I could write as well (If I could assume that a null list is equivalent to an empty list) :

or, again using old-style ternary operator:

Moreover, in my humble opinion, using Optional as parameters at least in public methods  a) create boilerplate code b) it doesn't prevent at all to pass nullable Optional values:

With respect to returned values, I think Optional may be useful to warn class users to be aware that a method may return an unitialized (or null) value and force them to proper check for null values.
For example,  I could write:

These are my two cents.
What do you think about ?
Posts: 21972
Eclipse IDE Spring VI Editor Chrome Java Ubuntu Windows
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree that you shouldn't use Optional as input arguments (with perhaps the odd exception here and there). If the item to search for or list is null, let the calling code handle how to deal with that. Using Optional for the return type is indeed warranted, and should have been used in old methods if it were available at the time.

One thing though: Optional.ofNullable(null) is effectively the same as Optional.empty(). Which actually is a reason it makes sense to disallow null for the item as well as the list; right now you couldn't see the difference between no match or a null inside the list, both return an empty Optional.

Oh, and a NoSuchElementException is a better choice than a regular Exception.
Posts: 6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I imagine a world where I don't have to do any null checks and be wary of NullPointerException. I personally use for return type where if the value is not present then an exception is not mean to be thrown. Allowing Optional as arguments or return type lets the developer know the intention of interface/method.
Could you hold this kitten for a sec? I need to adjust this tiny ad:
Thread Boost feature
    Bookmark Topic Watch Topic
  • New Topic