Java Code Geeks

Monday, December 29, 2014

Why Scala is hard to grasp for Java developers

Scala is a multi-paradigm language. It has characteristics of object oriented programming, functional programming, meta programming (language oriented programming or DSL). So a java programmer might write scala code which looks completely different than a Clojure or Haskell programmer writing the same scala code. This is because java developer might use more of Java style (mutable variables, for loops) whereas the developers from functional programming style might use more of functional aspect of scala.
Here is a sample example, different ways to calculate sum  of a List of Double.

 class Test {  
  def sum(data : List[Double]) : Double = {  
   //uses a mutable variable to produce the sum, this is most of the java developer might use  
   //but it is not the best way to do so. Because most of the functional language does not like  
   //to have mutable variable  
   var sum : Double = 0  
   data.foreach( v => sum = sum+v)  
   //Fold and Reduce are two techniques calculate the value at one shot (without mutable variable)  
   val totalSum = data.foldLeft(0.0D){ (total,n) =>  
    total + n  
   val anotherSum = data.reduceLeft[Double]{(acc,n) =>  
    acc + n  
   //now short hand of fold and reduce. Underscore is positionally matched arg  
   val yetAnotherSum = data.foldLeft(0.0D)(_+_)  
   println("Sum = " + sum + " total sum = " + totalSum + " and another sum = " + anotherSum + " yet another sum = " + yetAnotherSum)  
   return sum  

As a result, a new developer gets confused which is the right way of doing thing. Think that you write a piece of code and gave it for review and even reviewers fight over the right way of doing it.

Overall as a rule of thumb, I think it is better if we consider Scala as a "functional language" and try to use the best practices from functional world. This is why I have started advising Java developers to learn one functional language like Haskell or Clojure before picking up the "Scala" book. This tunes java developers mind towards functional world and come out of habits of using mutable variables or explicit for loops.

This is however a delicate topic and would love to hear more from users who transformed from Java to scala developer.

Thursday, July 24, 2014

Spring Annotations vs xml configurations

I faced this question myself while working on projects. There are many school of thoughts on this topic, however after practicing both the styles, I have come to a point where I can compile a list of guidelines when to use one vs the other. Here is my guideline

  1. If you follow clean architecture principles, you must have heard uncle Bob repeatedly saying "A good architecture allows us to defer critical decisions like UI,framework,database etc". If you want to use spring as a framework to manage dependencies among your beans, do you want to minimize spring dependencies or want to move out of spring framework in the future? If yes, then go for XML which externalizes the configurations. But then in real world, I have not seen any big project that started as a spring project and then later got converted to a JEE project, so if you are spring shop, no problem to use annotations.
  2. Are you writing a library/API which will be used by many teams? In that case, it is easier for everyone to read and understand the XML config. All the bean dependencies are in one place so it is easier to understand rather than downloading the source code of your library from maven repo and go through the code/annotations.
  3. If you need to use spring transactions, I recommend to use annotation. It is hard for a developer to understand that your methods need transaction if that is externalized to a XML config, rather if it is annotated in your class/methods that is easier to follow and understand.
  4. If it is a considerable size of a project and you care for application startup time, then pay attention to context component scan. It may take long time for spring to scan your classpath, read annotations to load all the annotated beans and their autowired dependencies. 
So both the methods are useful and that is why both of them are supported. Choose one over other or choose both according to your need. You can of course mix both the approaches in one project.

Wednesday, July 23, 2014

Discussion around TDD

Recently there have been quite a few discussions on TDD, its usefulness and whether it helps in design or not. It first started from a blog post from David Heinemeier Hansson(creator of Ruby on Rails) - TDD is dead. Later it became more interesting when David, Martin Fowler and Kent Beck (writer of Junit) started a discussion on google plus. The videos for this series can be found here .
Whether you are practicing TDD or not, I think this is a very good discussion to listen to.