Language Features Enhancing Trust

Alex just facepalmed.

if ( Boolean.TRUE.equals(employee.isHappy) ) {

“Wow, the human invention never ceases to come up with new ways to adorn boolean expressions! Too bad Eclipse doesn’t have a Quick Assist for simplifying them…”
Ah, one of those WWTC moments. That’s when the Show Annotation feature of Subversive comes in handy… which revealed that Bob is the author (unless he only adjusted the whitespaces in that line). “But he already left the office for today. Now, I’ll just simplify it and similar occurrences manually and tomorrow, I’m going to considerately mention to him that he could have written this condition umm… more concisely.” Alex pondered a bit over the commit message, but practiced self-restraint and wrote simply

Simplify boolean expressions...

(though he couldn’t help omitting those ellipses).
Next day, some of the tests of Bob’s module were failing.
– Hi Bob, could we have a look at your code? First, there are some red tests, and…
– Hmm, but I haven’t modified that module since yesterday. Let’s see the exception!
– Okay…

Exception in thread "main" java.lang.NullPointerException
at EmployeeLoader.loadEmployee(EmployeeLoader.java:41)

“Hmm, exactly the line I modified. But…” – thought Alex.
– …how could a simple condition without a single dereferencing cause a NPE?! – asked Bob, confused just like Alex.
– Uh-oh, I think I have a suspicion… Please show the declaration of isHappy…

private Boolean isHappy;

Alex facepalmed once again, but this time the cause was himself.
– NOOO! The dreaded autoboxing! But again, why isn’t it a primitive boolean?
– Hey, now I remember! Employees are parsed from XML using an autogenerated schema. The attribute isHappy is optional, so it might very well be null.
– Sorry, Bob. I feel silly for acting without asking you in advance or running the tests before committing. See, I couldn’t have imagined how this kind of change could break.
– Take it easy, Alex. 🙂 Now you can. In fact, I thought Boolean.TRUE would refer to the attribute’s type being non-primitive unambigously, and the Yoda condition would evoke the possibility of the null value immediately.
– I understand you, but to avoid such misunderstandings in the future, would you mind writing

if ( (employee.isHappy == null) && employee.isHappy ) {

to make it totally explicit that isHappy can be null? Or rather set an optional false value for this attribute in the schema?
– OK, I’ll consider.
Fortunately, Bob took the incident very lightly and his commit message was just:

Revert Alex's "simplifications" :)

The first thing Alex did was to set a warning for boxing and unboxing among the Java compiler settings. As he was accepting the changes, he thought: “Null and primitive types as well are billion dollar mistakes coming from arbitrary language design decisions which reflect implementation details. But at least they tought me to trust my fellow’s code – or at least to inspect the types before refactoring.”