I get never enough of vert.x, everything I watch this video it feels new.




Behavior Trait of an Engineer

I read an article almost 10 years back that describes the behavior of an engineer. At that time I was very impressed because it really explained my behavior. Last Friday when we were discussing why an engineer behaves like that I realized that most of the point that we discussed is answered in that article. After much effort and searching, I found that at

chocolatey rocks!

Its quite a long time since i opened my Windows machine and started setting up development environment. I was about to install all software then I realised that there is a fantastic package manager for Windows called chocolatey. It makes life much simpler. Simply run command like Linux and install the packages.


Reactive System

The concept of a reactive system has always fascinated me. How to design a system which can be resilient at the core with varying load and remain fault tolerant. I started exploring it with this course. When I started this course this seems like a black magic but as I keep exploring more and more this started making sense. Especially after going through below presentation.


Bitcoin economy and furure?

I was reading Chapter 8 “Bitcoin Economics and Currency Creation” of this book and realized that Bitcoin is like Gold, petroleum or any other natural resources. Its availability is limited. We can create only 21 million bitcoins and it is decreasing after every 4 years. When it first launched in 2009 there were 50 new bitcoins that became available every 10 minutes, and then it dropped to 25 bitcoin after four years; four years later it dropped to 12 ½ which is where it’s at now. So every 10 minutes on average, about 12 and a half bitcoin come into existence. That amount is going to reduce every four years in half until the year 2140 when the very last bitcoin will be awarded.

This is different from any other currency where central bank and print and supply the money to monetary system anytime. The limited supply of bitcoins makes it different than traditionally used currency. This difference makes me think that how it will impact the economy in long-term, considering if we are going to use bitcoin for the medium of exchange.

Here is my thought, on this. If people know that they have limited supply if bitcoins, they will start hoarding it, no one will spend money and this will push the value of bitcoin higher. As the value of bitcoin increases, the price of an item decreases(i.e you can buy the same quantity in 90 rupees, what you were buying in 100 rupees). As no one wants to spend their bitcoin because people know that value is going to increase and they can buy more stuff in future than they can do it now. This will push the economy into deflation loop. The main question is, is it good or bad?  My thought is that its neither good or bad? If you keep any intervention(say government or banks) this will stabilize by itself. Lower and lower price of the item encourages people to find a way to decrease the price and it encourages them to innovate. and moreover, once the price of the item is decreased enough, then people will again start spending them and it will eventually find an equilibrium.

The same is true for the inflationary economy, but here government or central bank had control and they can tweak the economy.

What I understand is that neither of the Inflationary or Deflationary economies is good or bad. Its the government intervention which makes things different and bitcoin will provide a way to bypass these interventions.

Java 8, default method

Before Java8 we have an only abstract method in the interface. But Java8 has removed this restriction and we can have methods with the body in the interface. An interface can have a default or static method. We will see what is the reason for adding default method.

Java8 has added lambda expression, this added many new methods in the already existing interface. Let us see this as an example. Here is the code for java.util.Iterator interface. This has 3 methods. There was a need to add lambda related method forEachRemaining in java8. Now assume a case where there is no default in the scene, then all the existing class which implements Iterator, needs to modify the implementation to add this new method. This needs to be done for JDK as well as application classes. This would have created problem and may have made all existing running application difficult to move to java8, i.e Java8 would not have been backward compatible.

The cleaver solution for this problem was to add a new default construct, which allows users to write method in the interface without the need to implement these in subclasses. Once we add default forEachRemaining method, it is automatically available for all the implementing class. This is fine. But what will happen when we implement two Interfaces and each of them has same default method.

The code will not compile. Here are 3 classes which have default method.

interface TestI1{
default void show(){
System.out.println("Default TestI1");
interface TestI2{
default void show() {
System.out.println("Default TestI2");
class Test implements TestI1, TestI2{
public static void main(String args[]) {
Test d = new Test();;

This will show following compilation error. error: class Test inherits unrelated defaults for show() from types TestI1 and TestI2 class Test implements TestI1, TestI2

We need to provide own implementation of the show method in Test class.

class Test implements TestI1, TestI2{
public void show(){
System.out.println("Test show");
public static void main(String args[]) {
Test d = new Test();;

Now how can we call the TestI1 and Test2 default show method? We can use super keyword to call super interfaces default method as shown below.

class Test implements TestI1, TestI2{
public void show() {;;
public static void main(String args[]){
Test d = new Test();;
Is’nt it a clever solution than making the java8 backward incompatible? 🙂

Revisit equals and hashCode contract

I have written a blog post about equals and hashCode contract. But now realised that this does not paint complete picture. There are some other scenario which needs to be covered.

Here is list of two videos which explain clearly about internal details about Hash based collection and why equals and hashCode contract is required in Java. I will try to explain all possible scenario that can be wrong when we don’t follow the contract.

Case 1 When class does nothing about equals and hashCode : When we do nothing to hashCode and equals method, each object will have their own default hashCode and these will be treated differently. Let’s assume if we have a HashSet of Employee object.

HashSet<Employee> employees = ….;

Employee key = new Employee….


When we try to fetch employee from employees, it will always return null. It is because of the fact that each Employee object will have unique hashSet(as we have not overriden hashCode method). When we try to find employee with key, there will be a very good probability that it maps to different bucket and will never be able to fetch the correct value. It is like finding a person’s home on wrong street.

Case 2 When class overrides equals but not hashCode :  It will not work because of the reason given above. equality with equals is checked, after going to a bucket. If we are in wrong bucket then even if equality returns true we are fetching wrong object. It is like two person having same house number but in two different address. If we could not find correct street number there will always be a good chance that we deliver our mail to wrong person.

Case 3 When class overrides hashCode wrong but forget to override equals :  Assume a case when we override hashCode to return a constant value(Say 100) for all objects and don’t override equals method. In this scenario, all values in the collection will map to a single bucket. When two object maps to same bucket, Java maintains a liked list to store these. So, in this scenario, we will end up with a linked list, which is inefficient. Lets check what happens when we try to fetch the value from linked list. As all object has same hashCode we will be able to reach the correct bucket, but it will always fails to do equality comparison(as Objects default equality checks memory address and two objects will never have same memory address).

Case 3 When class overrides hashCode wrong but override equals correctly:    Assume a case in which we override equals correctly but always return constant value(say 100) from hashCode. This will work correctly but the created Map will be inefficient as all value will be mapped to a single bucket and hence we virtually end with a Linked list.

Case 4 Correct implementation of hashCode and equals:  This works correctly as computed hashCode and equality  will solely depends on the state of the object and whenever we create new object with same value it will end with same hashCode and hence same bucket.