All variables in Java must be final

I haven't been using the final keyword in Java for 10 years, but more and more I think it's an excellent keyword in Java. All local variables should be declared final. Today one of the developers of my team made every local variable in a method final and I was wondering how strange that looked. But of course it was the right thing to do. Declaring all variables final will lead to less bugs (logic and typos e.g.).

public void doSomething(final input) {
   final result = calc(input);
}

If you reassign a variable you most probably do something wrong. I'll bet if you reassign a variable your method does at least two different things though every method should only do one thing. As should a class. Final also goes for method parameters, all should be final. Others think so too even for methods.

How do you deal with final attributes? When making most attributes final, just initialize them in the constructor. Immutable objects also play nicely with Tell, don't ask.

All these final keywords around your code create noise though. It would be best to have all variables automatically be final and have a new transient keyword for reassignable variables. Or at least for my IDE - Intellij IDEA - to hide the final keyword and write the variable in a different color. Hear me IDEA developers!

Update: After some more work with Scala, var and val are a good solution.

REST: Lean JSON and XML from the same code

Generating JSON and XML with the same code is difficult. One can create the semantically richer XML and convert it to JSON, but JSON notations for XML like Badgerfish look quite ugly to JSON advocates.

The problem at the core is that XML is typed whereas JSON is not. Every node in XML needs a type - it's name - for example <item><id>123</id><item>. JSON doesn't need such a type, { id: 123 } is fine for an item. { item: {id: 123}} looks too verbose. Especially getting to the data in Javascript: var id = item.item.id. The same goes for accessing arrays with var id = items[0].item.id; instead of var id = items[0].id;. The problem exists with other dynamic languages and data structures too, see Cobra vs. Mongoose for Ruby.

As I currently develop a REST based Jersey application in Java I needed a way to generate lean JSON and XML. Wouldn't it be best to have one code for both? DRY. My previous solution for generation JSON worked fine. The $(...) method calls create a node tree with nodes and lists. With a JsonRenderer and the Visitor pattern I generate JSON from the node tree. The problem was that this Java code

$( 
  $("id", listId),
  $("items", 
    ...
   )
);

creates nice JSON like { id: 123, items: [ ... ] }, but was unable to generate XML. As written above, the outer list has no type and a XmlRender therefor cannot render <shoppinglist><id>123</id>...</shoppinglist>.

The solution I thought about is to add type information to nodes which have no names.

$( type("shoppinglist"),
  $("id", listId),
  $("items",
    ...
  )
);

The implementation uses a simple static method and a Type class.

public static Type type(String name) {
    return new Type(name);
}

The type is attached to the node and if the node has no name but a type, the XmlRender uses the type instead of the name. The JsonRender doesn't use the type information and renders the same JSON as before. The piece of Java code now generates XML

<shoppinglist>
  <id>123</id>
  <items>
    <item><id>234</id><price></price><shop></shop>
      <description>Apple</description></item>
    <item><id>233</id><price></price><shop></shop>
      <description>Banana</description></item>
    </items>
</shoppinglist>

and lean JSON where neither shoppinglist nor item has a type

{ id: "123", items: [ { id: 234, price: "", shop: "", description: "Apple"}, { id: 233, price: "", shop: "", description: "Banana"} ]}

Next thing is to automatically apply the right renderer, toXml and toJson from within Jersey. The content negotiation then choses the accepted format for the client. Attributes (Meta-Information?) are not solved yet and I'm not sure if they are needed, or how to nicely add meta information to the $(...) tree. There is some discussion in the context of markup builders and attributes on James blog.

Probably the code will be released as an open source RESTkit if someone is interested.

Thanks for listening.