Why use Optional in Java 8+ instead of traditional null pointer checks?

Question

We have recently moved to Java 8. Now, I see applications flooded with Optional objects.

Before Java 8 (Style 1)

Employee employee = employeeServive.getEmployee();

if(employee!=null){
    System.out.println(employee.getId());
}

After Java 8 (Style 2)

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employee = employeeOptional.get();
    System.out.println(employee.getId());
}

I see no added value of Optional<Employee> employeeOptional = employeeService.getEmployee(); when the service itself returns optional:

Coming from a Java 6 background, I see Style 1 as more clear and with fewer lines of code. Is there any real advantage I am missing here?

Consolidated from understanding from all answers and further research at blog

Answer 1

Style 2 isn't going Java 8 enough to see the full benefit. You don't want the if ... use at all. See Oracle's examples. Taking their advice, we get:

Style 3

// Changed EmployeeServive to return an optional, no more nulls!
Optional<Employee> employee = employeeServive.getEmployee();
employee.ifPresent(e -> System.out.println(e.getId()));

Or a more lengthy snippet

Optional<Employee> employee = employeeServive.getEmployee();
// Sometimes an Employee has forgotten to write an up-to-date timesheet
Optional<Timesheet> timesheet = employee.flatMap(Employee::askForCurrentTimesheet); 
// We don't want to do the heavyweight action of creating a new estimate if it will just be discarded
client.bill(timesheet.orElseGet(EstimatedTimesheet::new));

Answer 2

If you're using Optional as a "compatibility" layer between an older API that may still return null, it may be helpful to create the (non-empty) Optional at the latest stage that you're sure that you have something. E.g., where you wrote:

Optional<Employee> employeeOptional = Optional.ofNullable(employeeService.getEmployee());
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

I'd opt toward:

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

The point is that you know that there's a non-null employee service, so you can wrap that up in an Optional with Optional.of(). Then, when you call getEmployee() on that, you may or may not get an employee. That employee may (or, possibly, may not) have an ID. Then, if you ended up with an ID, you want to print it.

There's no need to explicitly check for any null, presence, etc., in this code.

Answer 3

There is next to no added value in having an Optional of a single value. As you've seen, that just replaces a check for null with a check for presence.

There is huge added value in having a Collection of such things. All the streaming methods introduced to replace old-style low-level loops understand Optional things and do the right thing about them (not processing them or ultimately returning another unset Optional). If you deal with n items more often than with individual items (and 99% of all realistic programs do), then it is a huge improvement to have built-in support for optionally present things. In the ideal case you never have to check for null or presence.

Answer 4

As long as you use Optional just like a fancy API for isNotNull(), then yes, you won't find any differences with just checking for null.

Things you should NOT use Optional for

Using Optional just to check for the presence of a value is Bad Code™:

// BAD CODE ™ --  just check getEmployee() != null  
Optional<Employee> employeeOptional =  Optional.ofNullable(employeeService.getEmployee());  
if(employeeOptional.isPresent()) {  
    Employee employee = employeeOptional.get();  
    System.out.println(employee.getId());
}  

Things you should use Optional for

Avoid a value not being present, by producing one when necessary when using null-returning API methods:

Employee employee = Optional.ofNullable(employeeService.getEmployee())
                            .orElseGet(Employee::new);
System.out.println(employee.getId());

Or, if creating a new Employee is too costly:

Optional<Employee> employee = Optional.ofNullable(employeeService.getEmployee());
System.out.println(employee.map(Employee::getId).orElse("No employee found"));

Also, making everybody aware that your methods might not return a value (if, for whatever reason, you cannot return a default value like above):

// Your code without Optional
public Employee getEmployee() {
    return someCondition ? null : someEmployee;
}
// Someone else's code
Employee employee = getEmployee(); // compiler doesn't complain
// employee.get...() -> NPE awaiting to happen, devs criticizing your code

// Your code with Optional
public Optional<Employee> getEmployee() {
    return someCondition ? Optional.empty() : Optional.of(someEmployee);
}
// Someone else's code
Employee employee = getEmployee(); // compiler complains about incompatible types
// Now devs either declare Optional<Employee>, or just do employee = getEmployee().get(), but do so consciously -- not your fault.

And finally, there's all the stream-like methods that have already been explained in other answers, though those are not really you deciding to use Optional but making use of the Optional provided by someone else.

Answer 5

The key point for me in using Optional is keep clear when developer need check if function return value or not.

//service 1
Optional<Employee> employeeOptional = employeeService.getEmployee();
if(employeeOptional.isPresent()){
    Employee employeeOptional= employeeOptional.get();
    System.out.println(employee.getId());
}

//service 2
Employee employee = employeeService.getEmployeeXTPO();
System.out.println(employee.getId());

Answer 6

Your main mistake is that you're still thinking in more procedural terms. This is not meant as a criticism of you as a person, it's merely an observation. Thinking in more functional terms comes with time and practice, and therefore the methods isPresent and get look like the most obvious correct things to call for you. Your secondary minor mistake is creating your Optional inside your method. The Optional is meant to help document that something may or may not return a value. You might get nothing.

This has led you do write perfectly legible code that seems perfectly reasonable, but you were seduced by the vile twin temptresses that are get and isPresent.

Of course the question quickly becomes "why are isPresent and get even there?"

A thing that many people here miss is that isPresent() is that it's not something that is made for new code written by people fully on board with how gosh-darn useful lambdas are, and who like the functional thing.

It does however, give us a few (two) good, great, glamourous(?) benefits:

• It eases transition of legacy code to use the new features.
• It eases the learning curves of Optional.

The first one is rather simple.

Imagine you have an API that looked like this:

public interface SnickersCounter {
  /** 
   * Provides a proper count of how many snickers have been consumed in total.
   */
  public SnickersCount howManySnickersHaveBeenEaten();

  /**
    * returns the last snickers eaten.<br>
    * If no snickers have been eaten null is returned for contrived reasons.
    */
  public Snickers lastConsumedSnickers();
}

And you had a legacy class using this as such (fill in the blanks):

Snickers lastSnickers = snickersCounter.lastConsumedSnickers();
if(null == lastSnickers) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers);
}

A contrived example to be sure. But bear with me here.

Java 8 has now launched and we're scrambling to get aboard. So one of the things we do is that we want to replace our old interface with something that returns Optional. Why? Because as someone else has already graciously mentioned: This takes the guesswork out of whether or not something can be null This has already been pointed out by others. But now we have a problem. Imagine we have (excuse me while I hit alt+F7 on an innocent method), 46 places where this method is called in well tested legacy code that does an excellent job otherwise. Now you have to update all of these.

THIS is where isPresent shines.

Because now: Snickers lastSnickers = snickersCounter.lastConsumedSnickers(); if(null == lastSnickers) { throw new NoSuchSnickersException(); } else { consumer.giveDiabetes(lastSnickers); }

becomes:

Optional<Snickers> lastSnickers = snickersCounter.lastConsumedSnickers();
if(!lastSnickers.isPresent()) {
  throw new NoSuchSnickersException();
}
else {
  consumer.giveDiabetes(lastSnickers.get());
}

And this is a simple change you can give the new junior: He can do something useful, and he'll get to explore the codebase at the same time. win-win. After all, something akin to this pattern is pretty widespread. And now you don't have to rewrite the code to use lambdas or anything. (In this particular case it would be trivial, but I leave thinking up examples where it would be difficult as an exercise to the reader.)

Notice that this means that the way you did it is essentially a way to deal with legacy code without doing costly rewrites. So what about new code?

Well, in your case, where you just want to print something out, you'd simply do:

snickersCounter.lastConsumedSnickers().ifPresent(System.out::println);

Which is pretty simple, and perfectly clear. The point that's slowly bubbling up to the surface then, is that there exist use cases for get() and isPresent(). They're there for letting you modify existing code mechanically to use the newer types without thinking too much about it. What you're doing is therefore misguided in the following ways:

• You're calling a method that may return null. The correct idea would be that the method returns null.
• You're using the legacy bandaid methods to deal with this optional, instead of using the tasty new methods that contain lambda fanciness.

If you do want to use Optional as a simple null-safety check, what you should have done is simply this:

new Optional.ofNullable(employeeServive.getEmployee())
    .map(Employee::getId)
    .ifPresent(System.out::println);

Of course, the good looking version of this looks like:

employeeService.getEmployee()
    .map(Employee::getId)
    .ifPresent(System.out::println);

By the way, while it is by no means required, I do recommend using a new line per operation, so that it's easier to read. Easy to read and understand beats conciseness any day of the week.

This is of course a very simple example where it's easy to understand everything that we're trying to do. It's not always this simple in real life. But notice how in this example, what we're expressing is our intentions. We want to GET the employee, GET his ID, and if possible, print it. This is the second big win with Optional. It allows us to create clearer code. I also do think that doing things like making a method that does a bunch of stuff so that you can feed it to a map is in general a good idea.

Answer 7

I don't see benefit in Style 2. You still need to realize that you need the null check and now it's even larger, thus less readable.

Better style would be, if employeeServive.getEmployee() would return Optional and then the code would become:

Optional<Employee> employeeOptional = employeeServive.getEmployee();
if(employeeOptional.isPresent()){
    Employee employee= employeeOptional.get();
    System.out.println(employee.getId());
}

This way you cannot callemployeeServive.getEmployee().getId() and you notice that you should handle optional valoue somehow. And if in your whole codebase methods never return null (or almost never with well known to your team exceptions to this rule), it will increase safety against NPE.

Answer 8

I think the biggest benefit is that if your method signature returns an Employee you don't check for null. You know by that signature that it's guaranteed to return an employee. You don't need to handle a failure case. With an optional you know you do.

In code I've seen there are null checks that will never fail since people don't want to trace through the code to determine if a null is possible, so they throw null checks everywhere defensively. This makes the code a bit slower, but more importantly it makes the code much noisier.

However, for this to work, you need to apply this pattern consistently.

Answer 9

My answer is: Just don't. At least think twice about whether it's really an improvement.

An expression (taken from another answer) like

Optional.of(employeeService)                 // definitely have the service
        .map(EmployeeService::getEmployee)   // getEmployee() might return null
        .map(Employee::getId)                // get ID from employee if there is one
        .ifPresent(System.out::println);     // and if there is an ID, print it

seems to be the right functional way of dealing with originally nullable returning methods. It looks nice, it never throws and it never makes you think about handling the "absent" case.

It looks better than the old-style way

Employee employee = employeeService.getEmployee();
if (employee != null) {
    ID id = employee.getId();
    if (id != null) {
        System.out.println(id);
    }
}

which makes it obvious that there may be else clauses.

The functional style

• looks completely different (and is unreadable for people unused to it)
• is a pain to debug
• can't be easily extended for handling the "absent" case (orElse isn't always sufficient)
• misleads to ignoring the "absent" case

In no case it should be used as a panacea. If it was universally applicable, then the semantics of the . operator should be replaced by the semantics of the ?. operator, the NPE forgotten and all problems ignored.

---

While being a big Java fan, I must say that the functional style is just a poor Java man's substitute of the statement

employeeService
.getEmployee()
?.getId()
?.apply(id => System.out.println(id));

well known from other languages. Do we agree that this statement

• is not (really) functional?
• is very similar to the old-style code, just much simpler?
• is much more readable than the functional style?
• is debugger-friendly?

Answer 10

What would happen if "employeeService" is null itself? In both the code snippet, the null pointer exception will be raised.

It can be handled without using optional as:

if(employeeServive != null) {
    Employee employee = employeeServive.getEmployee();
    if(employee!=null){
        System.out.println(employee.getId());
    }
}

But as you can see there are multiple if checks and it can be grown to long hierarchy with a long nested structure like employeeService.getEmployee().getDepartment().getName()....getXXX().getYYY() etc.

To handle this type of scenarios, we can use Optional class as:

Optional.ofNullable(employeeService)
     .map(service -> service.getEmployee())
     .map(employee -> employee.getId())
     .ifPresent(System.out::println);

And it can handle any size of nesting.

To learn all about Java Optional, read my article for this topic : Optional in Java 8

Answer 11

Optional is a concept (a higher order type) coming from functional programming. Using it does away with nested null checking and saves you from the pyramid of doom.