val vs final

July 9, 2011

One of the things I see happening in Java code more frequently, is the appearance of additional final access modifiers on local variables. On member fields I really love the final access modifier because it makes my life as concurrency bug searcher, a lot easier. But I also see them more often on local variables like this:

void foo(final int x){
	final int z = 10;

Personally I find the added value of the final access modifier on these variables limited. In Scala I would go for it since it is just as easy to write a ‘val’ instead of a ‘var’ and a functional style of programming is promoted. But in Java the code tends to get ‘messy’ and method signatures are more often getting too long to place on a single line, which reduces readability.

That is why I’m questioning myself: how many bugs did I had in my 10+ years as developer, caused by a reassignment to a local variable? Perhaps I had them in the beginning, but I don’t know how long it has been. So why should a ‘fix’ be done on a non existing problem? And I like my methods short, so it is easy to see if something smelly is going on.

So unless it is some compiler optimization that is not triggered otherwise, or the variable is used in an anonymous inner class, I don’t see the added value of having final local variables in Java code

Placing them on local variables in an interface is just plain silly.

Akka and the Java Memory Model

July 7, 2011

There has been a lot of change in my life (professional and personal). I started working for Typesafe, the company behind Scala and Akka, where I can work-with/talk-to people like Martin Odersky, Jonas Boner, James Gosling and last but certainly not least, my personal hero: Doug Lea. And I moved to a different country (Bulgaria), the weather here is just great and my apartment looks out over the Black Sea. And I’m busy getting my body back in shape.

This is my first blogpost on the company blog, but I also wanted to have a link from this blog. So have a nice read!

Akka and the Java Memory Model.

Multiverse: STM for Scala? Part I

August 31, 2009

Multiverse is a Java based STM implementation and last week I have been playing with integrating Multiverse in Scala. And since I have no practical experience with Scala and the Java language is not going anywhere (any more) it sounded like a nice opportunity to get started with Scala.

Multiverse supports 2 models for creating atomic objects (objects managed by the STM) in the Java language. The simplest approach is adding an @AtomicObject annotation to a Pojo:

class Person{
   private int age;
   public int getAge(){return age;}
   public void setAge(int newAge){this.age = newAge;}

All changes made to person are atomic and isolated and the cool thing is that the get/setAge methods can participate in larger transactions (this solves the composability problem lock based approaches are suffering from). Using an @AtomicObject annotation is simple because you still can write normal Pojo’s.

The second model is using explicit refs (similar like Clojure refs).

class Person{
   private final Ref age = new Ref();
   public int getAge(){return age.get();}
   public void setAge(int newAge){age.set(newAge;}  

Multiverse doesn’t care which model is being used. The first has a better syntax and probably is going to perform better when the Pojo has more than 1 field (although it could also lead to false write-conflicts). But the second model is very easy to integrate with Scala and doesn’t rely on instrumentation. In the future the first model is going to be added to Scala as well, but I need to have a better understanding of how Scala is compiled to bytecode.

One of the cool things about Scala is that it is very easy to add new language constructs using closures. If we look at the atomic functionality (so wrapping a transaction around a set of operations) in Java, we need to write a lot of verbose code:

int sum = new AtomicTemplate(){
    public Integer run(Transaction t){
         return person1.getAge()+person2.getAge()

But in Scala you can say:

val sum = atomic{person1.age+person2.age}

Using the following closure:

 def atomic[E](body: => E): E = {
    new AtomicTemplate[E] {
      def execute(t: Transaction) = body

Isn’t that cool?

In the following blogposts I’ll explain the support for the retry and orelse mechanisms.