Goetz's First Law

"Its never any one feature that causes problems; it is the interaction of otherwise reasonable-seeming features."

In a recent conversation with a number of NFJS speakers, David Sletten (via his brother Brian) brought up a tricky Java puzzler - a piece of code that is seemingly simple, but doesn't do quite what you'd expect. Consider:

Arrays.asList(new Integer[] {1, 2, 3}).size();
Arrays.asList(1, 2, 3).size();
Arrays.asList(new int[] {1, 2, 3}).size();

To make a long story short, any reasonable first-reading of this code would expect all three examples to return '3', yet the bottom one returns '1'. Why?

Brian Goetz, who has the esteemed title of "Architect for the Java Language and Libraries" gave a clue that leads to the answer when he said "Hint: asList is a generic method. What type is being inferred for T?"

This led to a conversation that only the nerdiest of nerds lubricated with the finest of scotches would dare sit through. Brian eventually concludes with the statement, "The bipartite nature of the type system is the root cause here; int is not an Object, but int[] is. Mix that with varargs' attempt to conflate T... with T[], and...bam, astonishment. Its never any one feature that causes problems; it is the interaction of otherwise reasonable-seeming features."

That last sentence was quickly seized upon as a profound truth in software development and dubbed "Goetz's first law".

The code example above isn't nearly as important as the sentiment that inspired the law. Since he said that, I've seen virtually every problem I'm encountering as a variation of this.