Monday, September 15, 2014

SOLID object-oriented design

Do you know what SOLID (not solid, but S.O.L.I.D) object-oriented design stand for? It stand for: Single responsibility, Open-closed, Liskov substitution, Interface segregation and Dependency inversion.

This acronym is coined by Robert Martin. According to him, these principles make a backbone of solid object oriented design. You can read more about these principles in his book "Agile Software Development: Principles, Patterns, and Practices". I will try to describe these principles in following posts, but in a timely manner off course. :)

For starters here are his views on bad object oriented design and what should be avoided:
  • Rigidity - It is hard to change because every change affects too many other parts of the system.
  • Fragility - When you make a change, unexpected parts of the system break.
  • Immobility - It is hard to reuse in another application because it cannot be disentangled from the current application.

Sunday, September 14, 2014

Java built-in profiling and monitoring tools

Java profiling is very useful technique to find performance bottlenecks and/or to solve complete system failures. Common bug that can occur in any system size in Java are slow service, JVM crashes, hangs, deadlocks, frequent JVM pauses, sudden or persistent high CPU usage or even the dreaded OutOfMemoryError (OOME)

Finding this kind of bugs is like art and you need lot of experience to be good at it. That's why some of programmers specialize in Java profiling. In some cases fining bug is impossible if you don't know how system works. Every Java programmer should know at least what are basic profiling tools, because you can't always pay some external specialist to fix memory leaks or deadlocks for you.

Java comes with built-in tools for profiling and monitoring. Some of these tools are:

jmap

This is internal Java tool and it is not profiling tool as such, but it is very useful. Oracle describes jmap as an application that “prints shared object memory maps or heap memory details of a given process or core file or remote debug server”. And it is exactly that. Most useful option is to print memory histogram report. The resulting report shows us a row for each class type currently on the heap, with their count of allocated instances and total bytes consumed. Using this report you can easily identify memory leaks if you have any.

jstack

JStack is also not profiling tool, but it can help you identify thread deadlocks. The output of "jstack" is very useful for debugging. It shows how many deadlocks exist in this JVM process and stack traces of waiting threads with source code line numbers, if source codes were compile with debug options.

jconsole


JConsole is a graphical monitoring tool to monitor Java Virtual Machine (JVM) and Java applications both on a local or remote machine.  It is using for monitoring and not profiling, so you are better with using VisualVM described bellow.

VisualVM

Another tool currently built into the JVM is VisualVM, described by its creators as “a visual tool integrating several command line JDK tools and lightweight profiling capabilities”. This tool can generate memory graph that will show you how your application is consuming memory through time. VisualVM also provides a sampler and a lightweight profiler. Sampler lets you sample your application periodically for CPU and Memory usage. It’s possible to get statistics similar to those available through jmap, with the additional capability to sample your method calls’ CPU usage. The VisualVM Profiler will give you the same information as the sampler, but rather than sampling your application for information at regular intervals.

For me these built-in tools work quite well, but if you want more specialized and more powerful tools for profiling  you can check: BTrace, EurekaJ and Eclipse Memory Analyzer (MAT).




Friday, September 12, 2014

Transform if else (conditional) with polymorphism

Switch and consecutive if-else statements are not necessary anti-patterns, but you should consider using polymorphism in this situations, especially  if conditional is complex and long.
Sometimes when you refactor your code in this way, you actually learn something new about your data and make your code easier to follow.
Polymorphism also give you advantage when you have same conditional in through your code on several places and for example you want to introduce new branching, which in case of polymorphism will be just new type.

Let see it in example:
public class ConditionalPolymorphism {
    
    //smelly approach
    public int carSpeed(String car) {
        if ("Hyundai".equals(car)) {
            return 180;
        } else if ("Mazda".equals(car)) {
            return 160;
        } else if ("Nissan".equals(car)) {
            return 190;
        } else {
            throw new InvalidParameterException(
                    "Parameter not legal: " + car);
        }
    }

    //polymorphic approach
    public int carSpeed(Car car) {
        return car.speed();
    }

    public static void main(String[] args) {
        ConditionalPolymorphism conditionalPolymorphism = 
                new ConditionalPolymorphism();
        System.out.println(
                conditionalPolymorphism.carSpeed("Hyundai"));
        System.out.println(
                conditionalPolymorphism.carSpeed(new Hyundai()));
    }
}

interface Car {
    int speed();
}

class Hyundai implements Car {

    public int speed() {
        return 180;
    }
}

class Mazda implements Car {

    public int speed() {
        return 160;
    }
}

class Nissan implements Car {

    public int speed() {
        return 190;
    }
}
This is pretty simple and naive example, but you can see basic mechanics behind it. Polymorphic code is more elegant and it is written more in object-oriented manner. Also in this example you can omit parameter check, which will further reduce code complexity.

Saturday, September 6, 2014

Type Erasure and Bridge Methods in Generics

"Generics programming is about abstracting and classifying algorithms and data structures. It's goal is the incremental construction of systematic catalogs of useful, efficient and abstract algorithms and data structures"

-Alexander Stepanov

Generics programming concepts are nothing new. And it is not something Java introduced to the world (Ada, Eiffel and C++ supported generics even before Java did). In 1988 David Musser and Alexander Stepanov introduced and defined this concept.

Java introduced Generics in 2004 (Java 5) and implement it as type erasure. Type erasure consist of following steps:

  • Replace all type parameters in generic types with their bounds or Object if the type parameters are unbounded. The produced bytecode, therefore, contains only ordinary classes, interfaces, and methods.
  • Insert type casts if necessary to preserve type safety.
  • Generate bridge methods to preserve polymorphism in extended generic types.
You can conclude from this, that generics in java are purely compile time feature. Because of this, generics in Java incur no run-time overhead and it is important to point this out. I suspect they implement Generics as compile time correctness because they were focused on backward compatibility.

Here is simple demonstration of replacing generics type with their bounds. In this case bound is Object. I know there are better ways of copy array to collection (like Collections.addAll method), but this is only for demonstration purpose, so I will stick with it. ;)
public static <T> void array2Coll(T[] a, Collection<T> c) {
  for (T o : a) {
    c.add(o);
  }
}
After type erasure code will look like this:
public static void array2Coll(Object[] a, Collection c) {
  for (Object o : a) {
    c.add(o);
  }
}
As you can see, generics type has been replaced with Object type (it's upper bound). If their bound would be something else (for example <T> extends Comparable), then generics would be replaced by Comparable.

Sometimes compiler create a synthetic method, called a bridge method, as part of the type erasure process. Next examples will explain why and when compiler create this methods.
public class Node<T> {
  private T data;

  public Node(T data) { this.data = data; }
    public void setData(T data) {
      System.out.println("Node.setData");
      this.data = data;
    }
  }

public class MyNode extends Node<Integer> {
  public MyNode(Integer data) { 
    super(data); 
  }

  public void setData(Integer data) {
    System.out.println("MyNode.setData");
    super.setData(data);
  }
}
After type erasure compiler will create one synthetic bridge method for second class:
public class Node {

  private Object data;

  public void setData(Object data) {
    System.out.println("Node.setData");
    this.data = data;
  }
}

public class MyNode extends Node {

  public MyNode(Integer data) { 
    super(data); 
  }

  // synthetic bridge method
  public void setData(Object data) {
    setData((Integer) data);
  }

  public void setData(Integer data) {
    System.out.println(Integer data);
    super.setData(data);
  }
}
In this example bridge method was created because MyNode class was missing setData method for Object parameter. Without this method we wouldn't have proper polymorphic behavior and next example would throw ClassCastException.
  MyNode mn = new MyNode(5);
  Node n = mn;  
  n.setData("Hello"); //throws ClassCastException