Hey Mark, we missed the point here !


I was recently watching Mark Reinhold‘s interview on Oracle Technology Network. Mark is Principal Engineer at Sun Oracle and works on OpenJDK and future Java SE releases.

The interview went over many different subjects around Java SE : projects coin (simplification), jigsaw (modularity), closures (…)

Mark was also insisting on the many –ities of the Java platform : security, availability, scalability, readability, …

One of my favorite is readability ! It is important to understand how a piece of code is expected to behave just by reading it.  This helps to reduce bugs when we write code and / or to easily catch bugs when reading code written by our peers.

Java SE 5, released about 5 years ago, introduced a feature called auto boxing, allowing to mix and match Java’s primitive types (such as int, boolean, …) with their Object counterpart (such as Integer, Boolean, …)

The objective of autoboxing is to simplify code and increase readability and, as such, is a welcome addition. But the devil lies into the details.

The example of code below shows incoherent behavior introduced by auto boxing :

Integer integer1 = 127;
Integer integer2 = 127;
System.out.println(integer1 == integer2); //true

Integer integer3 = 128;
Integer integer4 = 128;
System.out.println(integer3 == integer4); //false

You read it right : the first equality is true, while the second is false.

I would expect either both expressions to be false (Object references never must be compared for equality, my grand mother learned me) Or both expressions to be true (should auto boxing fullfil its promises).

This weird behavior is caused by some compiler optimizations happening behind the scene.  When the compiler is auto boxing values between -128 and 127, it always reuse the same Object instance.  In our example, integer1 and integer2 are therefore references to the same Integer object, hence the first equality.

For values outside of this (-128, 127) range, the compiler creates different Object instances for each reference, even when the values are identical.

We all learned that we should not use object references when comparing values, but auto boxing encourages us to write such code and when doing so, we end up with incoherent behaviors such as the one described above, which can make bugs very difficult to catch.

Hey Mark, if readability is really a concern : we missed the point with auto boxing !

[UPDATE 3 May 2011]

@jplandrain on Twitter points me to the Java specs where this optimization is specified. See the last sentence of the paragraph.

, ,

  1. No comments yet.
(will not be published)