His weary brows barely raised anymore. The firefights and VP escalations of years past had taken their toll. He barely felt anything anymore.

But today, the senior engineer was faced with code that stopped him in his tracks.

public void generateQuery(Optional<RangeBoundary> from, Optional<RangeBoundary> to) {

  Optional.of(new RangeBoundary(LOWER_RANGE)),
  Optional.of(new RangeBoundary(UPPER_RANGE)));

"Why did the junior engineer use Optionals in this way"? Surely it could be written much simpler by using an if statement?


public void generateQuery(RangeBoundary from, RangeBoundary to) {
  if (from != null) 
  if (to != null) 

He could no longer keep scrolling through the pull request. He had to summon and question the junior engineer to understand.

"Why did you do it this way?"

"This is the new way", gleaned the young lad. You could see the word "elegant" already forming on his lips.

The senior engineer stopped for a moment and doubted himself - is this really better? After all, newer things are better than older things. He had heard others denounce NULL checking as a billion dollar mistake. And maybe by avoiding an explicit if statement, the JVM would somehow be able to chop through this code without having to consider those pesky branches.

Was it better?

"No, no. It can't be", he tried to reason. There were extra CPU cycles to create the wrapper class, then even more to garbage collect it. The method parameter itself was still nullable, so opportunities for misuse were still present. Even more so, as the junior probably didn't understand the technicalities of value-based classes.

This code did not belong in a robust, high performance system.

The senior engineer started by explaining that Java's Optionals were created for method return types. But before he could convince to the young engineer, a buzz interrupted.

It was the support staff.

The main CD pipeline was failing on a broken NPM dependency for the is-odd package.

The end.