DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports
Events Video Library
Refcards
Trend Reports

Events

View Events Video Library

Zones

Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks

Generative AI has transformed nearly every industry. How can you leverage GenAI to improve your productivity and efficiency?

SBOMs are essential to circumventing software supply chain attacks, and they provide visibility into various software components.

Related

  • Java Enterprise Matters: Why It All Comes Back to Jakarta EE
  • Unraveling Lombok's Code Design Pitfalls: Exploring Encapsulation Issues
  • Legacy Code Refactoring: Tips, Steps, and Best Practices
  • Two Cool Java Frameworks You Probably Don’t Need

Trending

  • Understanding k-NN Search in Elasticsearch
  • Designing Microservices Architecture With a Custom Spring Boot Starter and Auto-Configuration Framework
  • Stop Building Monolithic AI Brains, Build a Specialist Team Instead
  • Why Traditional CI/CD Falls Short for Cloud Infrastructure
  1. DZone
  2. Coding
  3. Java
  4. Java 8 Optional - Avoid Null and NullPointerException Altogether - and Keep It Pretty

Java 8 Optional - Avoid Null and NullPointerException Altogether - and Keep It Pretty

By 
Yannick Majoros user avatar
Yannick Majoros
·
Sep. 27, 14 · Interview
Likes (9)
Comment
Save
Tweet
Share
200.7K Views

Join the DZone community and get the full member experience.

Join For Free

There have been a couple of articles on null, NPE's and how to avoid them. They make some point, but could stress the easy, safe, beautiful aspects of Java 8's Optional. This article shows some way of dealing with optional values, without additional utility code.

The old way

Let's consider this code:

String unsafeTypeDirName = project.getApplicationType().getTypeDirName();
System.out.println(unsafeTypeDirName);

This can obviously break with NullPointerException if any term is null.

A typical way of avoiding this:

// safe, ugly, omission-prone
if (project != null) {
    ApplicationType applicationType = project.getApplicationType();
    if (applicationType != null) {
        String typeDirName = applicationType.getTypeDirName();
        if (typeDirName != null) {
            System.out.println(typeDirName);
        }
    }
}

This won't explode, but is just ugly, and it's easy to avoid some null check.

Java 8

Let's try with Java 8's Optional:

// let's assume you will get this from your model in the future; in the meantime...
Optional<Project> optionalProject = Optional.ofNullable(project);

// safe, java 8, but still ugly and omission-prone
if (optionalProject.isPresent()) {
    ApplicationType applicationType = optionalProject.get().getApplicationType();
    Optional<ApplicationType> optionalApplicationType = Optional.ofNullable(applicationType);
    if (optionalApplicationType.isPresent()) {
        String typeDirName = optionalApplicationType.get().getTypeDirName();
        Optional<String> optionalTypeDirName = Optional.ofNullable(typeDirName);
        if (optionalTypeDirName.isPresent()) {
            System.out.println(optionalTypeDirName);
        }
}

As noted in a lot of posts, this isn't a lot better than null checks. Some argue that it makes your intent clear. I don't see any big difference, most null checks being pretty obvious on those kind of situations.

Ok, let's use the functional interfaces and get more power from Optional:

// safe, prettier
Optional<String> optionalTypeDirName = optionalProject
        .flatMap(project -> project.getApplicationTypeOptional())
        .flatMap(applicationType -> applicationType.getTypeDirNameOptional());
optionalTypeDirName.ifPresent(typeDirName -> System.out.println(typeDirName));

flatMap() will always return an Optional, so no nulls possible here, and you avoid having to wrap/unwrap to Optional.

Please note that I added *Optional() methods in the types for that. There are other ways to do it (map + flatMap to Optional::ofNullable is one). The best one: only return optional value where it makes sense: if you know the value will always be provided, make it non-optional. By the way, this advice works for old style null checks too.

ifPresent() will only run the code if it's there. No default or anything.

Let's just use member references to express the same in a tight way:

// safe, yet prettier
optionalProject
        .flatMap(Project::getApplicationTypeOptional)
        .flatMap(ApplicationType::getTypeDirNameOptional)
        .ifPresent(System.out::println);

Or if you know that  Project has an ApplicationType anyway:

// safe, yet prettier
optionalProject
        .map(Project::getApplicationType)
        .flatMap(ApplicationType::getTypeDirNameOptional)
        .ifPresent(System.out::println);


Conclusion

By using Optional, and never working with null, you could avoid null checks altogether. Since they aren't needed, you also avoid omitting a null check leading to NPEs. Still, make sure that values returned from legacy code (Map, ...), which can be null, are wrapped asap in Optional.

Java (programming language) IT

Opinions expressed by DZone contributors are their own.

Related

  • Java Enterprise Matters: Why It All Comes Back to Jakarta EE
  • Unraveling Lombok's Code Design Pitfalls: Exploring Encapsulation Issues
  • Legacy Code Refactoring: Tips, Steps, and Best Practices
  • Two Cool Java Frameworks You Probably Don’t Need

Partner Resources

×

Comments

The likes didn't load as expected. Please refresh the page and try again.

ABOUT US

  • About DZone
  • Support and feedback
  • Community research
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Core Program
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 3343 Perimeter Hill Drive
  • Suite 100
  • Nashville, TN 37211
  • [email protected]

Let's be friends: