Friday, March 16, 2012

Why they don’t like Sri Sri



Sri Sri Ravi Shankar did not become famous because of his name. He took care of that long ago, by differentiating it from the already famous sitar player. He did not become famous because he had friends in high places. He did not have a headstart to reach where he is today. He started alone and all he did was share some of what he knew. You can argue that yoga, pranayam and meditation have always been known and there's nothing new in what he does. The bottom line is people liked what he had to offer and they kept coming to him. Like it or not, spirituality was not fashionable until Sri Sri.

Whatever it was that he did, he did it long enough and well enough to be known all over the world today. So far so good and things would have been fine if this was all it was. But the trouble is that he doesn't want to stop at that. He seems to want to be everywhere. It would've been fine if he had stuck to teaching breathing exercises, working in villages, reforming prisoners, teaching organic farming, planting trees etc. No problem. But when he wants to be active on political issues, mediate on issues he doesn't need to, voice opinions on matters that are not spiritual, well, that's a problem. Because then, he is encroaching, edging past people who had headstarts, who have the right surnames. And that is a serious breach of territory.

He can close his eyes today and put his finger on any city in India and gather lakhs of people there. Which politician today in India can do that? The strength of his popularity and connection with people, all these years, was visible only in the form of service projects like trauma relief. No matter where disaster strikes in the world, he is able to mobilize people and resources, even during the floods in Sindh last year. Good, more importantly, harmless.

But when that strength is moved from fringe issues, that affect a section of society, to core issues, that affect the bulk of the population, it starts shaking the seat of power. Suddenly, there is a fear that he may have political aspirations. Jesus, after all, was crucified on that very accusation. It starts showing up in remarks like "Swamiji, stick to spirituality, leave the politics to us." The condescension gives away that someone is rattled.

Sri Sri Ravi Shankar embarked on a tour of Pakistan a few days ago. You don't agree with what he does, fine. You question his intentions, it's your right. But by any account, somebody as widely known as him, going from India on a peace mission to Pakistan is big news. Consider the ground work: He has managed to portray spirituality in a way that nobody finds it an infringement in a religiously orthodox atmosphere. His volunteers directed relief operations in a country where our government has no influence. He has been able to tap the significant but unexpressed sentiment - “Fine, whatever, let’s just be friends now”. He has created a demand for himself when nobody in Pakistan has a reason to welcome anything or anybody from India. The breakthrough is historic, at the very least. Nope, not to our media. Peace mission? Boring.

Our media likes to believe that people love watching them sit in their studios and argue over the day's developments in sophisticated vocabulary. These people reach millions of people on a daily basis. But they are so busy being full of themselves, that they fail to connect with common people. How many times have you heard anybody say anything nice about any of our news channels or newspapers? Nobody today has a kind word for the media and you have to say, they’ve worked very hard to get there.

Without any support from this media, Sri Sri connects with people on the ground, in millions. Why? He adds value to their life, in some way or the other. You can choose to remain skeptic, or unimpressed by what he says but you cannot deny that what he does requires extraordinary commitment. He may well be the most traveled human being in the world today, and since planes are still recent to our civilization, in all of history.

It was not easy going to Pakistan. Apart from those who regularly criticize him because they find him elementary, for this trip, he had to face opposition from the fundamentalists on both sides. "Who are you to interfere? Who asked you? Let the governments handle it." We have seen what the governments have achieved over the last 60 years. It is beyond them. This issue requires a large-heartedness impossible for politicians. Making policies or signing documents does not bring the hearts of people together.

People are very simple and they connect to his simplicity. What he is doing may not be sensational but it's solid. What is sensational is forgotten within days, what he is doing will be remembered much longer. This was an opportunity for our media to show some class. Skepticism is healthy, cynicism is not. Skepticism keeps windows open to find reality, cynicism closes them all and shuts you from reality. And the reality is that today, you cannot ignore Sri Sri. He IS everywhere.

These words from Mahatma Gandhi make a great quote, but nobody thought of them as a prophecy: First they ignore you, then they laugh at you, then they fight you, then you win. The sad part is that “they” are our own people.

If you liked the above, help me blow it all over social media.



Loads of Love,
Ravi

Tuesday, March 13, 2012

Difference between HashMap and HashTable?


The HashMap class is roughly equivalent to Hashtable.


  1. hasMap is not synchronized(not thread-safe) whereas hashTable is synchronized(thread-safe)

  2. hashMap permits null values in key and value whereas hashTable does not allow nulls.

  3. hashMap does not guarantee that the order of the map will remain constant over time whereas with hashTable, order is constant over time.

  4. Iterator in hashMap is fail-safe while the enumerator for hashTable is not so.

  5. hashMap throws ConcurrentModificationException if any other Thread modifies the map structurally by adding or removing any element except Iterator's own remove() method. But this is not a guaranteed behavior and will be done by JVM on best effort.





HashMap can be synchronized


Map m = Collections.synchronizeMap(hashMap);



Note on Some Important Terms




  1. Synchronized means that only one thread can modify the hashTable at any point of time.

    Basically, it means that any thread before performing an update on a hashtable will have to acquire a lock on the object while others will wait for lock to be released.



  2. Fail-safe is relevant from the context of iterators.

    If an iterator has been created on a collection object and some other thread tries to modify the collection object structurally, a concurrent modification exception will be thrown.

    It is possible for other threads though, to invoke set() method since it doesn't modify the collection structurally.

    However, if prior to calling set(), the collection has been modified structurally, "IllegalArgumentException" will be thrown.



  3. Structurally modification means deleting or inserting element which could effectively change the structure of map.


How HashMap works in Java


HashMap works on principle of hashing (i.e. key-value pair is stored using hashCode value).

We have put() and get() method for storing and retrieving data from hashMap.

When we pass an both key and value to put() method to store it on hashMap, hashMap's implementation calls hashcode() method on that key object to identify a bucket location for storing the value object.

HashMap stores both key+value in the bucket. This is essential for the retrieving logic.





Note:

  1. hasCode() of key is used to identify bucket.

  2. Bucket is used to store "Key+Value" pair.

  3. HashMap stores bucket in a linked list.






What will happen if two different HashMap key objects have same hashcode?
Collision Occurs


Since hashcode() is same, bucket location would be same and collision occurs in hashMap.

Since HashMap use a linked list to store in bucket, "Key and Value" object will be stored in next node of linked list.




Collision Resolution


We can find the bucket location by calling the hasCode function on the key object.

After finding bucket location, we will call keys.equals() method to identify correct node in linked list and return associated value object for that key in HashMap.




What happens to HashMap in Java if the size of the Hashmap exceeds a given threshold defined by load factor?

OR

What is re-hashing?


If the size of the map exceeds a given threshold defined by load-factor e.g. if load factor is 0.75, hashMap will act to re-size the map once it filled 75%.

Java Hashmap does that by creating another new bucket array of size twice of previous size of hashmap, and then start putting every old element into that new bucket array and this process is called rehashing because it also applies hash function to find new bucket location.




Race condition on HashMap in Java


Race condition exists while resizing hashmap in Java. If two threads, at the same time, find that Hashmap needs resizing, they both try resizing the hashMap.
In the process of resizing of hashmap, the element in bucket(which is stored in linked list) get reversed in order during the migration to new bucket, because java hashmap doesn't append the new element at tail, instead it appends the new element at head to avoid tail traversing.
If race condition happens then you will end up with an infinite loop.



Using immutable, final object with proper equals() and hashcode() implementation would act as perfect Java HashMap keys and improve performance of Java hashMap by reducing collision.
Immutability also allows caching the hashcode of different keys which makes overall retrieval process very fast and so String and various wrapper classes e.g Integer provided by Java Collection API can be very good HashMap keys.



In terms of usage HashMap is very versatile and mostly used as cache. For performance reasons, we need caching a lot, HashMap comes as very handy there.

How HashMap works in Java


HashMap works on principle of hashing (i.e. key-value pair is stored using hashCode value).

We have put() and get() method for storing and retrieving data from hashMap.

When we pass an both key and value to put() method to store it on hashMap, hashMap's implementation calls hashcode() method on that key object to identify a bucket location for storing the value object.

HashMap stores both key+value in the bucket. This is essential for the retrieving logic.





Note:

  1. hasCode() of key is used to identify bucket.

  2. Bucket is used to store "Key+Value" pair.

  3. HashMap stores bucket in a linked list.






What will happen if two different HashMap key objects have same hashcode?
Collision Occurs


Since hashcode() is same, bucket location would be same and collision occurs in hashMap.

Since HashMap use a linked list to store in bucket, "Key and Value" object will be stored in next node of linked list.




Collision Resolution


We can find the bucket location by calling the hasCode function on the key object.

After finding bucket location, we will call keys.equals() method to identify correct node in linked list and return associated value object for that key in HashMap.




What happens to HashMap in Java if the size of the Hashmap exceeds a given threshold defined by load factor?

OR

What is re-hashing?


If the size of the map exceeds a given threshold defined by load-factor e.g. if load factor is 0.75, hashMap will act to re-size the map once it filled 75%.

Java Hashmap does that by creating another new bucket array of size twice of previous size of hashmap, and then start putting every old element into that new bucket array and this process is called rehashing because it also applies hash function to find new bucket location.




Race condition on HashMap in Java


Race condition exists while resizing hashmap in Java. If two threads, at the same time, find that Hashmap needs resizing, they both try resizing the hashMap.
In the process of resizing of hashmap, the element in bucket(which is stored in linked list) get reversed in order during the migration to new bucket, because java hashmap doesn't append the new element at tail, instead it appends the new element at head to avoid tail traversing.
If race condition happens then you will end up with an infinite loop.



Using immutable, final object with proper equals() and hashcode() implementation would act as perfect Java HashMap keys and improve performance of Java hashMap by reducing collision.
Immutability also allows caching the hashcode of different keys which makes overall retrieval process very fast and so String and various wrapper classes e.g Integer provided by Java Collection API can be very good HashMap keys.



In terms of usage HashMap is very versatile and mostly used as cache. For performance reasons, we need caching a lot, HashMap comes as very handy there.