Optional adds honesty to Type system and Method signature.

As a android developer its easy to explain this with java sample code. I am attempting make things clearer by the things you already know.

For example consider hypothetical classes Employee and Company. Company contains collection of employees. Simple enough to understand. addEmployee(Employee employee) method is skipped for brevity.

package com.vk;
import java.util.*;
* Class representing a Company contianing employees.
public class Company {
    private final List<Employee> employees;
    public Company() {
//Create a Collection to store Employees instances
employees = new ArrayList<Employee>();
* Search the employees collections for an Employee with firstname.
* (for simplicity assume All employees have unique name)
* @param firstName
* @return instance of Employee
public Employee getEmployee(String firstName) {
for(Employee employee : employees) {
.equalsIgnoreCase(firstName)) {
return employee;

/* What this null represents? Employee does not exist */
return null;


Employee Class represents employee of a company. For simplicity employee Id, employee designation etc… fields are skipped.

package com.vk;
* Basic Employee Class with FirstName and LastName
public class Employee {
   private final String firstName;
private final String lastName;
   public String getFirstName() {
return firstName;
   public String getLastName() {
return lastName;
   public Employee(String firstName, String lastName) {
this.firstName = firstName;
this.lastName = lastName;

This is plain old vanilla Java, nothing fancy.

Look at the method

Employee getEmployee(String firstName)

This signature implies given a first Name return me a employee of type Employee for given first name. We will visit this signature again in a bit..

In mathematical terms this can be explained as, getEmployee is function which takes first name of type String as input and outputs object of type Employee from Employee set. This can be depicted as association of first Names to Employees using two sets.

function associating firstname to employee

From the above picture its clear that there is no employee by name Mary in Employee Set. How do explain/convey this in code?(java way return null which does not belong to Employee set, compiler does not complains about this). Now look at the method

//Always returns Employee type.(Java you are lying...)
Employee getEmployee(String firstName)

When mary is passed as first name we are returning null in the code. what this represents? Employee with mary does not exist in company. How does null belong to Employee Set? NOO… You got it… Method signature is not Honest (Its not explicit about the intent of the function). Its hard to explain in java from the method signature that getEmployee outputs a employee of Employee Type OR employee does not exist in the Employee set. (You can argue that we can create Null Object of Type Employee..). This argument itself suffice that this type of abstraction should be present at language level.

Now we can rewrite the method in java like. Still its not at the language level. May be it will be added in Java 9 or 10 or 11….

Optional<Employee> getEmployee(String firstName)

Thats where languages like Kotlin and Swift shines. They have this support at the language level, so that compiler/editor will make sure that as programmer you test for nullability else code will not compile and enforces you think about the code you are writing.

Kotlin signature of the same method:

fun getEmployee(firstName : String?) : Employee?

Swift signature of the same method:

func getEmployee(firstName : String?) -> Employee?

Compiler stresses or make sure that caller of this method knows exactly what this method returns. A employee or null. Being explicit about it. Hopefully I am able to convince that Optional adds honesty to the method signature”. What does this mean to developer? this feature at language level turns runtime error to compile time error.(NPEs are caught at compile time not by going thru stack traces in lengthy logs from production.)

More details about null from its creator.

I call it my billion-dollar mistake. It was the invention of the null reference in 1965. At that time, I was designing the first comprehensive type system for references in an object oriented language (ALGOL W). My goal was to ensure that all use of references should be absolutely safe, with checking performed automatically by the compiler. But I couldn't resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.