Java 7 - Short declarations

Peter Ahe recently blogged about shortening the code needed for declaring variables, where he proposed static factory methods. I just wanted to note down my opinion on this area and why.

Short declarations

The problem to be solved is the excessive length of defining a variable, particularly as half the information is repeated. For example:

SomeVeryLongClassname foo = new SomeVeryLongClassname();

Why do we actually need to say 'SomeVeryLongClassname' twice for example? The current proposals for changing this are:

// now
SomeVeryLongClassname foo = new SomeVeryLongClassname();

// option A
foo := new SomeVeryLongClassname();

// option B
final foo = new SomeVeryLongClassname();

// option C
var foo = new SomeVeryLongClassname();

// option D
SomeVeryLongClassname foo = SomeVeryLongClassname.new();

// option E
SomeVeryLongClassname foo = new ();

Now, lets repeat the options using the classic map example:

// now
Map<String, List<Integer>> foo = new HashMap<String, List<Integer>>();

// option A
foo := new HashMap<String, List<Integer>>();

// option B
final foo = new HashMap<String, List<Integer>>();

// option C
var foo = new HashMap<String, List<Integer>>();

// option D
Map<String, List<Integer>> foo = HashMap.new();

// option E
Map<String, List<Integer>> foo = new HashMap<>();

// option E2
Map<String, List<Integer>> foo = new HashMap();

And finally, lets view the syntax options when applied to initialising the variable from a method:

// now
Map<String, List<Integer>> foo = loadHashMap();

// option A
foo := loadHashMap();

// option B
final foo = loadHashMap();

// option C
var foo = loadHashMap();

// option D
Map<String, List<Integer>> foo = loadHashMap();

// option E
Map<String, List<Integer>> foo = loadHashMap();

// option E3
Map<> foo = loadHashMap();

I hope that this is useful in comparing the main options being proposed.

My view is that options A, B and C are really very similar. They differ only in the exact syntax used to perform the inference. If I were forced to choose one of those three, I would probably choose C. However, I believe that all three are inappropriate for Java.

Why? One of the key tenets of Java is static typing. I believe that this manifests itself in Java-Style as variables always being fully declared at the point of creation (ie. on the LHS). This allows the maintainance developer to easily scan up the file and find what type the variable is that they are working with (Clarity, Intent and Readability). Options A, B and C do not meet this LHS declaration Java-Style rule.

A side effect of this is that the type of foo should be able to be declared to be a Map, and not a HashMap. Again, options A, B and C have no ability to do this.

So, I believe that options A, B and C are not acceptable if we are to stick with Java-Style in Java. I understand how dynamic language programmers may have no problems with these options and the kind of type-inference that they represent. I just don't believe that model is Java-Style.

Having ruled out A, B and C, we have D and E. Option D is only really of value in the map/list generics case. As such, it seems too specialist to me.

Option E has value in both the long class name and map/list generics cases. Dropping the RHS type doesn't clash with my proposal of defining the LHS as a key element of Java-Style. And without the RHS, object creation becomes significantly shorter.

(Option E2 is a really technical point to do with future reification of generics - not that important for this post.)

The downside of E is that it makes no difference when a factory or method is used on the RHS. But thats the inevitable result of defining the LHS as essential in Java-Style. This is tackled by E3, but again at the cost of losing LHS information, potentially breaking the Java-Style rule we've strived to create.

Summary

I believe that Java has a certain style, and its not the same as scripting languages. Part of that style is that the LHS of a declaration completely specifies the type. This rules out the options discussed elsewhere (A, B and C) and leads naturally to my favourite E (although I might be persuaded to accept E3).

As always feedback is welcomed. If possible could you mention if you regularly use a dynamic/type-inferring language, as I suspect views on this topic vary by how much people use, or have used, those languages.