Java Multithreading Steeplechase: Cancelling Tasks In Executors

…

Command Line Flags for the JVM

This post attempts to demystify command-line options of the Java Virtual Machine (JVM). I’m talking about those strange characters you often have to type when starting Java to run a program. The options are often used to specify environment variables (class path), configure  performance characteristics of the JVM (garbage collection frequency), amongst many other things.

For example, a sample of valid command line options are shown below in bold.

java -Xmx6g AClass
java -version
java -Xms4g -Xmx6g SomeClass
java -DSomeVal="foo" MyProgram
java -DSomeVal="foo" -cp MyProgram.jar -Xmx6g -XX:+UseCompressedOops -XX:+UseG1GC com.foo.Bar 

JVM also support many command-line options which allow users to specify:

• Minimum and Maximum Size of the Heap Memory
• Type of Garbage Collector
• Type of JIT Compiler (Client or Server), or,
• To display JVM version,
• etc.

Java Language Specification (JLS) breaks the command-line options into three categories based on their maturity level. The most mature options belong to a category called “Standard Options” and must be supported by all JVM’s. Less mature options are called “Non-Standard“. These are specific to JVM (e.g. HotSpot) and are subject to change between releases. There is also a third category of  options called “Developer Options“. Developer options are a shade of Non-Standard.

Quick Recap: JVM command-line options are used to specify configuration settings to control execution of the Virtual Machine. These options are broken into three categories as shown below:

1. Standard Options
2. Non-Standard Options
3. Developer Options (Experimental)

Let’s look at the categories in detail.

1. Standard Options

The Standard Options are regulated by the Java Virtual Machine Specification and must be supported by all implementations of Java Virtual Machines. For example, OpenJDK, HotSpot, etc. Standard Options are stable and do not change between releases. Standard Options begin with a – followed by the name of option, e.g. –version

Some standard options are shown below:

-version:  java -version

-cp:  java -cp <PATH>

-jar:  java -jar MyProgram.jar

-Dproperty=value:  java -DSomeVal="foo"

2. Non-Standard Options

Non-Standard Options always begin with -X.  The fact that they are not guaranteed to be supported in all implementations of the JVM or even between versions, did little to hurt their popularity. Non-Standard Options remain popular and are widely used. These options often specify an integer value with a suffix of k,m, or g to specify kilo, mega or giga. To get a list of all Non-Standard Options supported by your JVM, you can invoke the launcher with -X, e.g. `java -X`. Examples:

-Xms:  java -Xms2g 

-X:  java -X

3. Developer Options

Developers Options always begin with -XX.  They are also Non-Standard. They follow the following format for setting boolean Options: -XX: followed by either + or – to indicate true or false, followed by the name of option.

-XX:+UseCompressedOops (Indicates that the Option UseCompressedOops must be used)

From, Java Documentation:

• Boolean options are turned on with -XX:+<option> and turned off with -XX:-<option>.

• Numeric options are set with -XX:<option>=<number>. Numbers can include ‘m’ or ‘M’ for megabytes, ‘k’ or ‘K’ for kilobytes, and ‘g’ or ‘G’ for gigabytes (for example, 32k is the same as 32768).

• String options are set with -XX:<option>=<string>, are usually used to specify a file, a path, or a list of commands

Examples:

java -XX:+PrintCompilation

java -XX:+ParallelGCThreads=10

Click here for a complete list of Options from Oracle.

Object Naming Conventions in JMX

Every MBean must have a name, more accurately, an ObjectName. Although, MBean could be named anything, E.g. “DogBean” or “SunnyDay”, it is important to choose consistent and well defined names to avoid inflicting mental torture on the poor soul who is interacting with your application via JMX.

Fortunately, MBean names follow some standard conventions and names can determine how Clients display MBeans. MBean names look like this:

domain:key=property

Remember this convention. Read the last line carefully. Notice that there are two parts with a : separating them. The first part is called domain and the second part is called key-properties-list.

Here’s an example MBean name with both domain and properties: com.somecompany.app:type=ThreadPool

Domain Naming Conventions

The domain could be any arbitrary string, but it cannot contain a : since it is used as a separator. Slash (/) isn’t allowed as well. If the domain name is not provided, then the MBean shows up under “DefaultDomain“. As mentioned earlier, domain names should be predictable. According to Oracle Technet:

….if you know that there is going to be an MBean representing a certain object, then you should be able to know what its name will be.

And then add further:

The domain part of an Object Name should start with a Java package name. This prevents collisions between MBeans coming from different subsystems. There might be additional text after the package name. Examples:

com.sun.someapp:type=Whatsit,name=5
com.sun.appserv.Domain1:type=Whatever

Key=Property Naming Conventions

The property list is optional and is in the following format:

name=property

If you wish to specify multiple properties, separate each of them by comma(,). For example:

com.somecompany.app:type=ThreadPool,poolname=Parser,scope=internal

They Key=Property should be used to uniquely identify MBean Objects, such as, each Object in the same domain may have different properties. For example:

com.somecompany.app:type=ThreadPool,name=Parser

com.somecompany.app:type=ThreadPool,name=Generator

That’s MBean naming convention from  1000 feet. If you want to get more information, please read here.

Things every Java developer must know about Exception handling

… moved

Java Multithreading Steeplechase: Executors

Historical Perspective on Tasks & Threads

Tasks are activities that perform some action or do calculations. For example a task could calculate prime numbers up to some upper limit. Good tasks do not depend on other tasks: they are independent. In this post, when I refer to tasks, I would mean tasks that are independent.

Tasks in Java can be represented by a very simple interface called Runnable that has only one method: run(). The singular function neither returns a value nor can throw checked exceptions.

public interface Runnable {
    void run();
}

Many new comers to Java presume Threads to be the primary abstraction for running tasks. This means that a task can be submitted to a thread which then runs the task. In fact, the Thread class has constructors which take a Runnable for execution:

Thread(Runnable target)
Thread(Runnable target, String name)
Thread(ThreadGroup group, Runnable target)
...

There are obvious benefits in segregating tasks and threads.

A Task, defined by implementing Runnables, is submitted to Thread for execution. The Thread doesn’t know anything about the task and the same thread could run several different tasks.

Enter Executor:

Executor was introduced in Java 1.5 as a clean abstraction for executing tasks. Mantle was passed to Executor from Thread. According to the Java API, an Executor:

“… executes submitted Runnable tasks.  This interface provides a way of decoupling task submission from the mechanics of how each task will be run, including details of thread use, scheduling, etc.” In essence, Executor is an interface, whose simplicity rivals that of Runnable:

public interface Executor {
    void execute(Runnable command);
}

The ‘very simple’ Executor interface forms basis for a very powerful asynchronous task execution framework. It is based on a Producer-Consumer pattern: Producers produce tasks and Consumer threads execute these tasks.

ExecutorService

There is little chance you will use ever use Executor directly. It is very powerful, yet feature starved interface with a lone method for executing tasks. Fortunately for us, it has a famous child called ExecutorService, which provides lifecycle support such as shutdown, task tracking and the ability to retrieve results.

Tracking Task Progress via Future

ExecutorService defines a method called `submit(Runnable task)` which returns a `Future` that can be used to track task’s progress and cancel it (if desired). Future is an interface. From its javadocs:

“A Future represents the result of an asynchronous computation. Methods are provided to check if the computation is complete, to wait for its completion, and to retrieve the result of the computation. The result can only be retrieved using method get when the computation has completed, blocking if necessary until it is ready. Cancellation is performed by the cancel method. Additional methods are provided to determine if the task completed normally or was cancelled. Once a computation has completed, the computation cannot be cancelled.”

RunnableFuture

Earlier on, I said that the interface Runnable doesn’t return a value. Runnable tasks can indicate completion by modifying a shared data structure. RunnableFuture implements both Future and Runnable interfaces. It can be submitted to any method which expects Runnable and the Future allows to access its result.

So far we have only discussed interfaces (Executor, ExecutorService and Future). Before we look into concrete classes, let us consider one very important concept.

Thread Pool

A  design pattern: http://en.wikipedia.org/wiki/Thread_pool_pattern. It has a task queue which holds incoming tasks and has a pool of thread which takes tasks from the queue and execute them.

A sample thread pool (green boxes) with waiting tasks (blue) and completed tasks (yellow)

Benefits of Thread Pools are thread re-use (creating new threads is a significant CPU overhead) and improved responsiveness (there may already be a waiting thread when a task arrives).

Now let us discuss concrete classes.

AbstractExecutorService

This is a skeletal implementation for ExecutorService, providing default implementations for some of it’s methods.

public abstract class AbstractExecutorService
implements ExecutorService

ThreadPoolExecutor

This is an ExecutorService that applies the Thread Pool pattern to execute tasks. From its javadocs:

“An ExecutorService that executes each submitted task using one of possibly several pooled threads, normally configured using Executors factory methods.” It provides several methods for setting pool and task queue sizes. For more information:

public class ThreadPoolExecutor extends AbstractExecutorService
implements Executor, ExecutorService

FutureTask

Provides an implementation of Future and RunnableFuture. From its javadoc:

“…provides a base implementation of Future, with methods to start and cancel a computation, query to see if the computation is complete, and retrieve the result of the computation.”

Since a FutureTask implements RunnableFuture, you can submit it directly to an ExecutorService.

Callable:

Callable‘s were introduced in Java 5 as the next version of Runnable. Just like Thread passed mantle to Executor for task execution, Runnable passed mantle to Callable for representing tasks.

Callable for used to represent tasks. Unlike Runnable’s, they can return a value and even throw Exceptions. They even support generics.

Summary:

Executor and ExecutorService form a very powerful framework for asynchronous task execution. Future is a wrapper that provides a way to track a task’s progress and could be used to cancel it. Callable represents a task and allows the task to return a value and throw exceptions.

So you might ask why do we still have Threads and Runnables if we have better choices available, in the form of Executor and Callable. As far as Callable Vs Runnable is concerned, the reason is purely backwards compatibility. Threads are not languishing in Java. ExecutorService simply provides a cleaner abstraction for executing tasks. They still rely on Threads to execute these tasks.

Java Multithreading Steeplechase: Stopping Threads

… move to codeahoy.com

Java’s Iterator, ListIterator and Iterable Explained

Recall Collection: A container for Objects in Java. Example: ArrayList<E>, Vector<E>, Set<E>, etc.

 An iterator is an Object, which enables a Collection<E> to be traversed. It allows developers to retrieve data elements in a Collection without any knowledge of the underlying data structure, whether it is an ArrayList, LinkedList, Set or some other kind.

The concept behind iterator is very simple: An Iterator is always returned by a Collection and has methods such as next() which returns the next element in the Collection, hasNext() which returns a boolean value indicating if there are more elements in the Collection or not, etc.

Iterators promote “loose coupling” between Collection classes and the classes using these Collections. For example, a class containing some kind of an algorithm (e.g. Search) is only concerned with traversing the list without knowing the exact list structure or any low level details.

Interface Iterator<E>:

All Iterator objects must implement this interface and are bound by its protocols. The interface is very simple and only has three methods:

–       next() : Returns the next element in the Collection. To get all elements in a Collection, call this method repeatedly. When the end is reached and there are no more elements present, this method throws NoSuchElementException.

–       hasNext() : returns true if the Collection has more elements. false otherwise.

–       remove() : removes the last returned element from the Collection.

A java.util.Iterator can only move in one direction: forward. Once the iterator has reached the end of the list, it cannot be reset to the starting position again. In this case, a new Iterator should be obtained.

Interface ListIterator<E>:

This is a specialized Iterator for Collections implementing the List<E> interface. In other words, it is an iterator for Lists. It gives several advantages over Iterator namely:

1. It allows traversing in both directions: forward & backward
2. It allows for obtaining the Iterator position in the Collection, i.e. its index.
3. It allows for adding or removing elements of the underlying List. [set(..) works as well].

You must be wondering at this point, why a new kind of Iterator for Lists? Why can’t we use the plain old Iterator. But if you really think about it, you’ll see why: Let us say you have two Collections: a Set<E> and a List<E>. You get Iterators from both Collections to traverse the list. However, you feel that the Iterator returned by List can do more: It can return the current index, allow you to add an element to the list, etc. That’s where ListIterator’s come in. The Iterator returned by Set<E> doesn’t have to do any of this: an element as no position(index) in the Set<E> Collection etc.

Interface Iterable<E>:

Before I wrap this us, I want to discuss the Iterable<E> interface. It is a very simple Interface which defines only one method called iterator() which returns an Iterator<E>.

The sole purpose of this interface is to allow Objects implementing it to be used in for-each loop. A for-each loop in Java looks like the following:

for (String element: (Iterable)collectionImplemetingIterable) { //do something with element}

For example: ArrayList() implements Iterable. This allows you to pass an ArrayList() object to a for-each loop and traverse through it.

e.g.

ArrayList as = new ArrayList();
as.add(“hippo”);
as.add(“chicken”);
as.add(“duck”);

// traverse the List using for-each
for (String element : as)
	System.out.println(element);

Summary:

An iterator allows traversing a Collection. An Iterator could be obtained for virtually any kind of Collection, for example:

ArrayList as = …;
HashSet hs = ….;

Now let us get Iterators for the two Collections defined above:

Iterator asIterator = as.iterator();
Iterator hsIterator = hs.iterator();

To iterate over the two collections:

</pre>
while(asIterator.hasNext) //Iterate over ArrayList()
{
    System.out.println(asIterator.next());
}

while(hsIterator.hasNext) //Iterate over HashSet()
{
    System.out.println(hsIterator.next());
}

Notes:

• Java iterators are very much like Relational Database Cursors.
• Prior to Iterators, which were introduced in jdk1.2, programmers used enumeration to traverse Collections.

Skeletal Implementations in Java Explained

I use interfaces generously in my programs. I prefer them over using abstract classes for several reasons, some of which I will mention below:

1. Inheritance does not promote good encapsulation. All sub classes depend on the implementation details of the super class. This may result in broken sub classes when the super class is changed. (Imagine testing all sub classes every time you change the super class!)
2. Unlike inheritance, where a sub class can only extend from one super class, classes are free to implement as many interfaces as they like to support.
3. It is very easy to support a new interface in an existing class. Suppose you would like several of your classes to support a new type, say, Serializable. You can simply implement the interface in your classes and define the interface methods. For example, any class in Java can implement the Comparable interface and can be applied everywhere a Comparable type is expected.
   Note: This is called defining a mixin[1]. Comparable is a mixin type. These types are intended to be used by other classes to provide additional functionality.

The above three arguments go directly against the philosophy of abstract classes. A sub class can only have one parent class and abstract classes defeat the purpose of mixins (Imagine Comparable being an Abstract class).

Now that I have tried my best to convince you Inheritance is bad, let me say this:

“Inheritance has its own place in programming. It is helpful in many cases, and decreases programming effort”

This is best explained with an example. Suppose you are writing a program, which uses Redis to represent its data. You would like to create specialized classes that deal with certain types of data. For instance, a class could be created to open a connection to Redis Database #0 to store running counters and perform all related actions. Another class would connect to Redis Database #1 and store all users in a set who have requested to opt out from the service.

Let us define an Interface representing the main Redis Database:

interface RedisConnection {

    int connect();

    boolean isConnected();

    int disconnect();

    int getDatabaseNumber();
}

Lets write a Counters class which implement this interface:

class RedisCounters implements RedisConnection {

    @Override
    public int connect() {
        //... lots of code to connect to Redis
    }

    @Override
    public boolean isConnected() {
        //... code to check Redis connection
    }

    @Override
    public int disconnect() {
        //... lots of code to disconnect & perform cleanup
    }
 }

Finish by writing a class, which deals with users who have chosen to Opted Out in Redis.

class RedisOptOut implements RedisConnection {

    @Override
    public int connect() {

        //... lots of code to connect to Redis
    }

    @Override
    public boolean isConnected() {
        //... code to check Redis connection
    }

    @Override
    public int disconnect() {
       //... lots of code to disconnect & perform cleanup
    }

    	/**
      * Other code specific to handling users who have opted out
      */

    // method specific to this class
    public boolean isOptedOut(String userid) {….}
}

If you look closely at the two classes above, you’ll notice something is not right: both classes repeat the connect(), isConnected() and disconnect() functions verbatim. This type of code repetition is not good for several obvious reasons: imagine if you have 10 classes instead of just two, and you would like to change the way connect() function works. You’ll have to make edits in all 10 classes and test them.

Abstract Classes To the Rescue

The program in the last section, presents a classic case where abstract classes excel. We can have define an abstract super class which implement common functionality and make its methods final to restrict sub classes from overriding them. You’ll end up with some like the following:

abstract class RedisConnection {
	public final int connect() {
		// ... lots of code to connect to Redis
	}

	public final boolean isConnected() {
		//... code to check Redis connection
	}

	public final int disconnect() {
		// ... lots of code to disconnect from Redis and perform cleanup
	}
}

/**
 *  sub class which extends from RedisConnection
 *
 */
class RedisCounts extends RedisConnection {

	/**
	 * There is no need to define connect(), isConnected() and disconnect() as
	 * these functions are defined by the super class.
	 */

	/**
	 * Other code specific to storing and retreiving counters
	 */
}

/**
 * another sub class extending from RedisConnection
 *
 */
class RedisOptOut extends RedisConnection {
	/**
	 * There is no need to define connect(), isConnected() and disconnect() as
	 * these functions are defined by the super class.
	 */

	/**
	 * Other code specific to handling users who have opted out
	 */
}

No doubt, this is a better solution. But at the beginning of this post, I explained why interfaces are preferred over inheritance. Let us take this one step further and combine interfaces and abstract classes, to maximize the benefits.

Abstract Classes + Interfaces = Abstract Interfaces

We can combine Abstract Classes and Interfaces by providing an abstract class, which defines the basic functionality, with every interface where necessary. The interface defines the type, whereas the abstract class does all the work implementing it.

By convention, these classes are named: AbstractInterface [Interface is the name of the interface the abstract class is implementing]. This convention comes from Java. In the Collections API, the abstract class, which goes with the List interface, is called AbstractList, etc.

The key to designing these abstract classes or AbstractInterfaces is to design them properly and document it well for the programmers. For example, the class comment of the java.util.AbstractList class define the methods the programmers need to override in their implementations:

“To implement an unmodifiable list, the programmer needs only to extend this class and provide implementations for the get(int) and size() methods.

To implement a modifiable list, the programmer must additionally override the set(int, E) method (which otherwise throws an UnsupportedOperationException). If the list is variable-size the programmer must additionally override the add(int, E) and remove(int) methods.”[2]

Abstract Interfaces (Interfaces + Abstract Classes) give programmers the freedom to choose whether they would like to implement the interface directly or extend the abstract class. In our example, we will have:

/**
 * The Interface
 *
 */
interface RedisConnection
{
    int connect();
    boolean isConnected();
    int disconnect();
    int getDatabaseNumber();
}

/**
 * Abstract class which implements the interface.
 * This is called Abstract Interface
 *
 */
abstract class AbstractRedisConnection implements RedisConnection
{
    @Override
    public final int connect()
    {
        //... lots of code to connect to Redis
    }

    @Override
    public final boolean isConnected()
    {
        //... code to check Redis connection
    }

    @Override
    public final int disconnect()
    {
        //... lots of code to disconnect from Redis and perform cleanup
    }
 }

/**
 * A subclass which extends from the Abstract Interface
 *
 */
class RedisOptOut extends AbstractRedisConnection {…}

In cases where a class cannot extend from the AbstractInterface directly, it can still implement the Interface, and use an inner class which extends from the AbstractInterface and forward all interface method invocations to the inner class. For example:

/**
 * A class showing the forwarding technique. This class implements
 * an interface, but forwards all interface method invocations
 * to an abstract class, the Abstract Interface.
 */
class RedisCounters implements RedisConnection {

	// inner class extending Abstract Interface
	private class RedisConnectionForwarder extends AbstractRedisConnection {
		public void RedisConnectionForwarder() {
		}
	}
	RedisConnectionForwarder r = new RedisConnectionForwarder();

	@Override
	public int connect() {
		// Simply forward the request to the Forwarding class.
		return r.connect();

	}

	@Override
	public boolean isConnected() {
		// Simply forward the request to the Forwarding class.
		return r.isConnected();
	}

	@Override
	public int disconnect() {
		// Simply forward the request to the Forwarding class.
		return r.disconnect();
	}

	/**
	 * Other code specific to storing and retreiving **counters**
	 */
}

In cases where a class cannot extend from the AbstractInterface directly, it can still implement the Interface, and use an inner class which extends from the AbstractInterface and forward all interface method invocations to the inner class. For example:

/**
 * A class showing the forwarding technique. This class implements
 * an interface, but forwards all interface method invocations
 * to an abstract class, the Abstract Interface.
 */
class RedisCounters implements RedisConnection {

	// inner class extending Abstract Interface
	private class RedisConnectionForwarder extends AbstractRedisConnection {
		public void RedisConnectionForwarder() {
		}
	}
	RedisConnectionForwarder r = new RedisConnectionForwarder();

	@Override
	public int connect() {
		// Simply forward the request to the Forwarding class.
		return r.connect();

	}

	@Override
	public boolean isConnected() {
		// Simply forward the request to the Forwarding class.
		return r.isConnected();
	}

	@Override
	public int disconnect() {
		// Simply forward the request to the Forwarding class.
		return r.disconnect();
	}

	/**
	 * Other code specific to storing and retreiving **counters**
	 */
}

As a final technique, you can also use static factories returning concrete instances, which they implement, in form of anonymous inner classes.  For example:

/**
 * A static factory method
 */
public static RedisConnection getRedisCountersImpl(…)
{
	return new AbstractRedisConnection() {
		//...
        /**
	 * Other code specific to storing and retrieving counters
	 */

	}
}

Summary

Using Interfaces, as a general contract, has many benefits over Inheritance. Inheritance, however has its own place in programming, and often times is a necessary evil. In this post, we explored Abstract Interfaces which combine the power of Interfaces with Inheritance. Abstract Interface is a term for Abstract Class, which implements all the functionality of an Interface. Abstract Interfaces always go with the Interfaces they are supporting.

Abstract Interfaces gives programmers the freedom to use either the interface or the abstract class, instead of tying them with inheritance down like abstract classes. We explored two techniques of using abstract classes when extending from the Abstract Interface is not possible. The Java API uses abstract Interfaces graciously. The Collections API is filled with these: AbstractList, AbstractSet, AbstractMap, AbstractCollection.

References

[1] http://en.wikipedia.org/wiki/Mixin

[2] http://docs.oracle.com/javase/6/docs/api/java/util/AbstractList.html

Best Java Coding Practices @ Work

https://github.com/starscriber/coding-standards/wiki

Auto generating version & build information in Java

Until recently, I was relying on final Strings and longs to store version information in my programs. However, I soon faced the limitations of this approach such as forgetting to update version (or revision) information, conflicting maven and internal version information. So I switched to using java properties for handling version information and updating the properties at compile time using maven’s antrun plugins. This had its own short comings and resulted in complex pom.xml files.

I have to admit, I’m not a big fan of maven and its XML based structure: I don’t like it because its a gigantic beast. Every time I have to do something in maven, I find that I’m spending time researching online for the right plugin and looking up the documentation for the plugin of interest. As a developer, build management using maven should be the least of my concern {Not having to remember which maven plugin does what}. On the other hand, to be fair to maven, it has some cool features like dependency management, life cycle, convention based directory structure to name a few. But maven tried to do a lot of things, resulting in a complex product.

{At this point, I’m considering switching in Gradle. As I developer, I want to be spending time solving problems in the problem domain not trying to tame my build management system. But using Gradle requires grasp of Groovy (Yet Another Scripting Language – YASL) If only there was a build management system written in Python!!!!!! }

The solution which I’m going to discuss in this post uses Java annotations to generate versioning information at run-time using python scripts. Maven is used in a very limited way with this approach.

Steps

1. Create Version annotation and a class which reads these annotations in your Java program
2. Write a python script to write the Java annotation at runtime
3. Structure your pom.xml file to include generated-sources folder and running our python script

1. Create Version annotation and a class which reads these annotations in your Java program

The first step is to create an annotation holder in your program which you’ll annotate at the runtime. Example here.

Then create a class which is going to read the annotation information. Example here.

2. Write a python script to write the Java annotation at runtime

The next step is to create a python script to generates package-info.java containing build time & date, version string, hostname, etc. The way this works is by creating a package information which is used to provide overall information about package contents. We will fill our annotations in this class. Example of a python script is here. Feel free to use it in your projects.

3. Structure your pom.xml file to include generated-sources folder and running our python script

You then need to tell your maven file to pick up the package-info.java which is auto-generated by the python script in the last step. The python script places the ‘package-info.java’ in “targer/generated-sources/java” folder. I used the build-helper-maven plugin to include a new source folder. Example here.

The last step is to tell maven to run the python script in generate-sources phases. I used the exec-maven plugin for this. Example here.

Checkout the complete project

I have uploaded a complete project on Github: https://github.com/umermansoor/Versionaire

To use the project, do the following:

$ git clone git@github.com:umermansoor/Versionaire.git

$ cd Versionaire

$ mvn package

$ java -cp ./target/versonaire-1.0-SNAPSHOT.jar com._10kloc.versionaire.App