JDK Tools for your application

In this post, I will talk about various tools that help you analyze your Java application’s behavior when something has went wrong. This is not an exhaustive list but just the tools that I have used at some point of time and found useful.

1. jmap
This is a tool bundled within JDK and useful for connecting to either running java processes locally/remotely or connecting to a core file.

  • Heap Dump: jmap -dump:format=b,file=/tmp/heap.bin PID
    This command dumps the heap which can be later analyzed using other tools mentioned below to analyze the application’s memory usage.
  • Heap Summary: jmap -heap PID
    This command dumps the current memory usage with the division of heap space (Young Gen/Old Gen/Survivor Space) depending on the Garbage Collector used

2. jstack
This tool is also included in JDK and useful to get details of a running application.

  • Thread details: jstack -l PID
    This command will print the stack trace of all the threads running in the java process. This can be used to get total threads with priority details of those threads.

3. jhat
Bundled within JDK, this tool can be used to analyze the heap dump

  • Heap Dump Analysis: jhat Heap_Dump_File
    This command will analyze the heap dump file extracting all the object details and publish this details to a web server running on default 7000 port (can be changed using options) where you can see all the object details and even run Object Queries (OQL) against the heap dump.

4. jvisualvm
This tool is also available within JDK and provides UI to connect to running java process and can be used to get a heap dump or used as a profiler.

5. MAT
Memory Analyzer Tool is an eclipse plugin used for heap dump analysis and very useful to find memory leaks or checking the heap usage of the application. More about MAT: MAT. This tool also provides the details of unreachable objects useful to study the behavior of Garbage Collector.

6. GCViewer
When the Java application is started, it can be asked to dump garbage collector logs using options like –XX:+PrintGCDetails –XX:+PrintGCTimeStamps and -Xloggc:logFile to redirect the logs to a file for further analysis.

GCViewer reads the GC logs to provide a summary of how the garbage collector performed.

Design Pattern: Builder Pattern

What is it?

According to Gang of Four, “Separates the construction of a complex object from its representation so that the same construction process can create different representations.” Again, no idea reading it for the first time :)

So, stated simply, we try to separate the construction of a complex object from its representation to reuse the building process for creating different representations.

Let’s take an example of subway, where we provide all the details of vegetables and sauces needed (data) and we get the sandwich (complex object). Here, we did not tell how to prepare it (building process). This is what we want to do with object creation process too.

In software world:

To create a sandwich object, you pass all the parameters in the constructor to create the object. This can get worse if we have multiple constructors with different parameters.

Improvement #1:

Remove the parameters from the constructor and set all the properties you need. Something like:

 Sandwich sandwich = new Sandwich();
 sandwich.setBreadType(BreadType.WHITE);
 sandwich.setHasMayo(true); ...

But, now we need to check if we have set all the properties. We have no way to set the order. I mean, you need to provide the bread type before vegetables and sauce you need that can not be controlled anymore. So, we need a builder that takes all details and build it using proper steps.

Improvement #2:

class SandwichBuilder{
       Sandwich sandwich;

       public Sandwich getSandwich(){
             return sandwich; 
       }

       public void createSandwich(){
              sandwich = new Sandwich();
              sandwich.setBreadType(BreadType.WHITE);
              .... 
       }
}

It can be further modified to modularize and make the building process more meaningful with functions doing smaller tasks being called from createSandwich

       public void createSandwich(){
              sandwich = new Sandwich();
              selectBreadType();
              addVegetables();
              addSauces();
              .... 
       }

So, now we have a builder whose object can be used to create a new sandwich having same properties using this builder.

Also, this helps when creation of the complex object (sandwich here) changes i.e. we can change the code inside the build function (createSandwich here).

One more advantage here is if we have more than one kind of complex object (different types of sandwich), just create a new builder class to handle that and we can reuse the creation of the complex object de-coupling it from its representation.

But, now we need to create multiple builder classes with similar functions without any relation between them (no common interface implemented by them) and much of code will be replicated in these builders.

Improvement #3

Create an abstract class controlling the structure of the builder which can be used by each builder to use the same procedure with different values (ingredients here):

abstract class SandwichBuilder{
        Sandwich sandwich;

        public Sandwich getSandwich(){
               return sandwich;
        }

        public void createNewSandwich(){
               sandwich=new Sandwich();
        }

        public abstract void addVegetables();
        public abstract void addSauces();
        ....
}

So, this class here now encapsulates the commonalities between the builders but who handles the procedure of building the sandwich.

It should not be added here as this is the class that does the work common to all the builders. Here is what we do to mitigate this:

class SandwichMaker{
      private SandwichBuilder builder;

      public SandwichMaker(SandwichBuilder builder){
             this.builder = builder;
      }

      public void buildSandwich(){
             builder.createNewSandwich();
             builder.selectBread();
             builder.addVegetables();
             builder.addSauces();
      }

      public Sandwich getSandwich(){
             return builder.getSandwich();
      }
}

So, now our builder class just handles the properties (ingredients here) to create the complex object and the creation steps are handled by the maker and your code using this will look something like this:

      SandwichMaker maker = new SandwichMaker(new MyFavSandwichBuilder());
      maker.buildSandwich();
      Sandwich sandwich = maker.getSandwich();

The Builder Pattern Design:

Director (SandwichMaker) <>——- Builder (SandwichBuilder) <———- ConcreteBuilder (MyFavSandwichBuilder) ——-> Product (Sandwich)

So in Hollywood terms:

Director knows how to build

ConcreteBuilder defines the steps for creation of the Product used by Director

Where to use:

  • Need to create a complex object with lot of details embedded into it.
  • Multiple data combination to create multiple types of products using same steps.

Design Pattern: Bridge Pattern

Definition:

According to Gang of Four, “Decouple an abstraction from its implementation so the two can vary independently”. If you did not understand it, it is pretty normal :) Lets discuss it in detail.

Lets understand the definition:

So for any kind of abstraction, we create an interface and implement that interface in a class. Now, our client code uses this interface to call the implemented code. But, every time the interface changes, we need to change the implemented code. How can we de couple the abstraction and its implementation?

Example:

We have different types of documents that have print functionality in them and we have created a abstract super class GenericDocument that has this print method.

Now lets say we get a requirement to have a Document to have two different types of printing (ex. remove images while printing). One option is to create a new subclass of that Document and implement print accordingly.

  • But what if all documents may need this new type of Print tomorrow? Do we create a new subclass every time?
  • What if we get multiple different print types. Should we create a new sub class for each type of document?

Solution:

To have a generic print that can be used by each type of document if needed, we can create a print helper that can handle each type of print request and this helper can be used by each document’s print method without the need of any new sub class creation for each new print type.

GenericDocument <— Book, Research Paper, Design Document

Create a PrintHelper interface that has two implementations: NormalPrint and PrintWithoutImages implementation.

Now, GenericDocument has PrintHelper passed in the constructor that can be used by each document’s print method solving the whole purpose.

What this pattern did?

Abstraction (GenericDocument) uses Implementor (PrintHelper)

RefinedAbstraction (Book, Research Paper etc.) uses ConcreteImplementor (NormalPrint, PrintWithoutImages)

When to use it?

You have some abstraction (GenericDocument) and some implementations (Book, Research Paper etc.) already existing but you need to add some functionality (Print without images) that can be used by all the implementations, you can go ahead and use bridge pattern.

Design Pattern : Adapter Pattern

What is Adapter Pattern?

Lets say you need to use a library that expects a particular interface and client code (that needs to call the library) currently expects a particular generic interface which is not supported by the library.

What should be done?

Change the client to use the new interface and call the library to solve the purpose. What if few years later, you need to use another library that uses a completely new interface?

Should we change the client code again to suite the new interface?

What does this pattern solve?

  • Allow clients to use other code and work together which otherwise could not use due to incompatible interfaces
  • Lets say you are writing a useful functionality that you think is reusable for variety of users, then you can provide the Adapter support so that clients can implement the adapter to suit there use cases.

Solution

In such cases, adapter patterns come to rescue solving these problems. Lets see how:

Naming convention:

Client: You code that needs to use some functionality exposed by third party code you do not have control upon.

Adaptee: The implementation you need to use

Adapter: The interface that is used by the client to use Adaptee’s operation

ConcreteAdapter: Implements Adapter and calls Adaptee providing the results back to client.

Client —> Adapter (Interface) —> ConcreteAdapter (Implementation) —> Adaptee

Points to consider

  • Apart from the mentioned use case, it can also be used in the implementation to de couple your code from the implementation.
  • For example, you can use it to handle which db your code connects to. Just create one Adapter implementation for each db you want to support.

Scala: Part 4: Classes & Objects

This post will focus on basics of OOP in Scala.

Basics

As we all know, Class is a blueprint of object. A simple class with no variables & methods:

scala> class SimpleClass{}
defined class SimpleClass

scala> var obj=new SimpleClass
obj: SimpleClass = SimpleClass@1364ee5

Member variables: Can be defined using var or val.

Methods: Can be defined using the keyword def as used to define functions.

You must provide initial values of variables in the class

scala> class Person {var name}
<console>:1: error: '=' expected but '}' found.
class Person {var name}
                      ^
scala> class Person {var name=""; var age=0}
defined class Person

scala> p.name="Rasesh"

scala> p.age=24

scala> println(p.age)
24

Now, check the difference between var and val in terms of reference to object:

scala> val p1=new Person
p1: Person = Person@18a80d4

scala> p1=new Person
<console>:6: error: reassignment to val
p1=new Person
  ^

You can change the variables in the object pointed by p1 but not the object being pointed by p1.

Default access in Scala is public for the variables defined. To make it private:

scala> class Person {private var name=""; private var age=0}
defined class Person

scala> var p=new Person
p: Person = Person@9578c1

scala> p.name="Rasesh"
<console>:6: error: variable name cannot be accessed in Person
p.name="Rasesh"

You cannot access or change the fields in the object as they are defined private. So, we will need to add getters and setters in the class:

scala> class Person {private var name=""; def getName() : String = {return name}; def setName(nm: String): Unit = {name=nm} }
defined class Person

scala> val p=new Person
p: Person = Person@1450337

scala> p.setName("Rasesh")

scala> println(p.getName())
Rasesh

Unit is similar to void in Scala. If you don’t specify any return value, it is assumed to be a procedure returning no value i.e. Unit.

The values passed as argument in methods are val, and hence cannot be changed. See an example:

scala> class Person {private var name=""; def getName() : String = {return name}; def setName(nm: String): Unit = {nm="new name"} }
<console>:4: error: reassignment to val
class Person {private var name=""; def getName() : String = {return name}; def setName(nm: String): Unit = {nm="new name"} }

The “return” keyword is not mandatory in Scala and in absence of it returns the last value computed by the method.

scala> def f(): Unit = "this string is lost"
f: ()Unit

scala> f

scala> def g() = "this string is not lost"
g: ()java.lang.String

scala> g
res16: java.lang.String = this string is not lost

scala> def h() { "this string is also lost" }
h: ()Unit

scala> h

scala> def g(): String = { "this string is also lost" }
g: ()String

scala> g
res18: String = this string is also lost

Singleton Objects

Scala does not have static members but it has singleton objects. A singleton object definition looks similar to class but with the keyword “object”

object Person{
var staticInt=0
val person=new Person
person.name="Rasesh Mori"
person.age=24

def greetPerson(): String = "Hello "+person.name+" static int: "+staticInt
}

The singleton object’s name is the same as the class defined above.

When a singleton object shares the same name with a class, it is called that class’s companion object. You must define both the class and its companion object in the same source file. The class is called the companion class of the singleton object. A class
and its companion object can access each other’s private members.

Singleton object is similar to home of static fields in Java. I can also hold methods as described in previous object (greetPerson) and it can be accessed as follows:

$ cat person.scala
class Person{
   private var name=""
   private var age=0

   def getName() : String = name
   def setName(nm: String) { name = nm }

   def getAge() : Int = age
   def setAge(ag: Int) {age=ag}
}

object Person{
   var staticInt=0
   val person=new Person
   person.name="Rasesh Mori"
   person.age=24

   def greetPerson(): String = "Hello "+person.name+" static int: "+staticInt
}

Person.staticInt=1
println(Person.greetPerson())

$ scala person.scala
Hello Rasesh Mori static int: 1

Singleton object acts similar to static block in Java and is executed once it is accessed.

A singleton object that does not share the same name with a companion
class is called a standalone object. You can use standalone objects for many
purposes, including collecting related utility methods together.

Scala Application:

To run a Scala program, you must supply the name of a standalone singleton
object with a main method that takes one parameter, an Array[String],
and has a result type of Unit.

Now, we make some changes in previous “person.scala” file and add a new file “runPerson.scala” as follows:

$ cat person.scala 
class Person{
	private var name=""
	private var age=0

	def getName() : String = name
	def setName(nm: String) { name = nm; Person.staticInt=1 }

	def getAge() : Int = age
	def setAge(ag: Int) {age=ag}
}

object Person{
	var staticInt=0
	val person=new Person
	person.name="Rasesh Mori"
	person.age=24

	def greetPerson(): String = "Hello "+person.name+" static int: "+staticInt
}

$ cat runPerson.scala 
object PersonMain {
	def main(args: Array[String]) {
		val p=new Person
		p.setName(args(0))
		p.setAge(args(1).toInt)
		println(p.getName()+" "+p.getAge())
	}
}

Let’s compile them using scalac, Scala compiler:

$ scalac person.scala runPerson.scala

This creates class files for corresponding classes as shown below:

$ ls *.class
Person.class Person$.class PersonMain.class PersonMain$.class

Now, let’s run the application. Don’t be confused looking at class files that it will be interpreted by ‘java’ but there is a special interpreter that we already used, scala

$ scala PersonMain Rasesh 24
Rasesh 24

Ok. Enough for today. Let’s see what we learn new next time.

<= Previous Post

Scala: Part 3 : Sets & Maps

I will continue with some more data structures offered by Scala.

As Scala focuses on both imperative and functional programming, it offers both immutable and mutable implementations of below mentioned data structures:

1. Using Sets

scala> var jetSet = Set("Boeing","Airbus")
jetSet: scala.collection.immutable.Set[java.lang.String] = Set(Boeing, Airbus)

scala> println(jetSet)
Set(Boeing, Airbus)

Using Set’s apply method (i.e. using parenthesis remember??), by default, it uses immutable implementation of Set as mentioned in the output.

scala.collection.mutable.* contains mutable implementations whereas
scala.collection.immutable.* contains immutable implementations.

“+=” method can be used to append to it. Mutable objects include them whereas immutable objects create new objects to incorporate new element.

scala> jetSet+="Lear"

scala> println(jetSet)
Set(Boeing, Airbus, Lear)

scala> jetSet.+=("Lear2")

scala> println(jetSet)
Set(Boeing, Airbus, Lear, Lear2)

To use mutable set:

scala> import scala.collection.mutable.Set
import scala.collection.mutable.Set

scala> var mutableJetSet=Set("Boeing","Airbus")
mutableJetSet: scala.collection.mutable.Set[java.lang.String] = Set(Airbus, Boeing)

scala> mutableJetSet += "Lear"

scala> println(mutableJetSet)
Set(Airbus, Lear, Boeing)

HashSet is also available in both the implementations:

scala> var hashSet = HashSet("Tomatoes", "Potatoes")
<console>:4: error: not found: value HashSet
var hashSet = HashSet("Tomatoes", "Potatoes")
^

scala> import scala.collection.immutable.HashSet
import scala.collection.immutable.HashSet

scala> var hashSet = HashSet("Tomatoes", "Potatoes")
hashSet: scala.collection.immutable.Set[java.lang.String] = Set(Tomatoes, Potatoes)

scala> import scala.collection.mutable.HashSet
import scala.collection.mutable.HashSet

scala> var mutableHashSet = HashSet("Tomatoes", "Potatoes")
mutableHashSet: scala.collection.mutable.Set[java.lang.String] = Set(Tomatoes, Potatoes)

2. Using Maps:

Again, they are both mutable and immutable available in the same packages.

scala> import scala.collection.mutable.Map
import scala.collection.mutable.Map

scala> val battingOrder = Map[Int, String]()
battingOrder: scala.collection.mutable.Map[Int,String] = Map()

scala> battingOrder += (1 -> "Shikhar Dhawan")

scala> battingOrder += (2 -> "Rohit Sharma")

scala> battingOrder += (3 -> "Virat Kohli")

scala> println(battingOrder(2))
Rohit Sharma

Again, HashMap implementations are provided in both the packages.

Now, battingOrder += (2 -> "Rohit Sharma") is internally converted by Scala Compiler as battingOrder.+=((2).->("Rohit Sharma"))

So, here first “->” method is called returning a tuple that is passed to “+=” method.

<= Previous Post                                                                                               Next Post =>

Scala: Part 2: Arrays, List & Tuples

I will continue exploring more features in Scala here.

1. Parameterize Array with types:

val big = new java.math.BigInteger("12345")
$ cat 6_arrays.scala
val greetScala = new Array[String](3)

greetScala(0) = "Hi "
greetScala(1) = args(0) + ", "
greetScala(2) = "Welcome to Scala!\n"

for(str <- greetScala)
print(str)

$ scala 6_arrays.scala Rasesh
Hi Rasesh, Welcome to Scala!

Use of parenthesis makes a call to method apply of the first object passing values in the parenthesis as arguments to method called apply.

In the previous example, greetScala(0) is translated to greetScala.apply(0). It is true for any object that has method called apply.

Also, Scala has no operators in traditional sense. Its just functions names +,-,/,*. It seems weird if you are not familiar with functional programming but this is how its done in most languages like Lisp and Scheme.

This means 1+2 is a call to method called ‘+’ and its passed 2 as argument. Its same as (1).+(2)

scala> 1+2
res0: Int = 3

scala> (1).+(2)
res1: Int = 3

Similarly, when used on left side of ‘=’, parenthesis are replaced by a call to update method as in greetScala(0) = "Hi " is equivalent to greetScala.update(0, "Hi ")

Note: Everything in Scala, from arrays to expressions are objects with methods.

Initialize an array without specifying datatype:

val numNames = Array("zero", "one", "two")

This is similar to calling Array.apply(“zero”,”one”,”two”). We can assume apply to be a static function in Array class.

2. Using Lists:

List are immutable elements as in functional programming languages Lisp, Scheme etc. It means once created list elements do not change. It is similar to String class in Java.

scala> val oneTwo=List(1,2)
oneTwo: List[Int] = List(1, 2)

scala> val numStr=List(1,"str")
numStr: List[Any] = List(1, str)

List has a method ‘:::‘ for list concatenation. As it is a method, it can also be used with dot operator as mentioned previously (a catch here, explained after :: operator) and explained in example below:

scala> val concatenated = oneTwo ::: numStr
concatenated: List[Any] = List(1, 2, 1, str)

scala> println(concatenated)
List(1, 2, 1, str)

scala> val con2=(oneTwo).:::(numStr)
con2: List[Any] = List(1, str, 1, 2)

Original List oneTwo is not mutated.

scala> println(oneTwo)
List(1, 2)

Another operator on list is ‘::‘ which has exactly the same purpose as ‘cons’ in Scheme, if you are familiar with it. It considers the left element as the first element of the new list appended by the list on the right side of the operator.

scala> val newList = 0 :: oneTwo
newList: List[Int] = List(0, 1, 2)

scala> val nestedList = oneTwo :: numStr
nestedList: List[Any] = List(List(1, 2), 1, str)

scala> oneTwo.::(numStr)
res2: List[Any] = List(List(1, str), 1, 2)

The output of oneTwo :: numStr should be same as oneTwo.::(numStr) as per our understanding so far. But, we see something else here. In Scala, when a method name ends with a ‘:’, the calling object is on the right side and the passed object in the one on left. This means oneTwo :: numStr is equivalent to numStr.::(oneTwo).

‘Nil’ or List() is used to specify empty list which is equivalent of ‘() or empty in Scheme. To create a list 1,2,3 in Scheme, one can write (cons 1 (cons 2 (cons 3 ‘()))). Similarly, in Scala, you can write

scala> val oneTwoThree = 1 :: 2 :: 3 :: Nil
oneTwoThree: List[Int] = List(1, 2, 3)

This is just an introduction to list. There are many more list operations supported by Scala.

3. Using Tuples:

Tuple is a combination of multiple values of any data type similar to ‘pair’ in C++ STL but not limited to 2 values. In Java, you need to create a class of 2 variables to return multiple values from a method, but it can be done using tuples in Scala.

Tuples are immutable like List.

scala> val pair = (1, "Hi", 4.5)
pair: (Int, java.lang.String) = (1,Hi,4.5)

scala> println(pair._1)
1

scala> println(pair._2)
Hi

scala> println(pair._3)
4.5

First element is referred by _1 element and second one by _2 and so on.

Further exploration of language in next posts.

<= Previous Post                                                                                            Next Post =>