If you read my double brace post, you might find it very handy. However, sometimes you might be warned by PMD or Checkstyle for this kind of usage. Because they don’t like this kind of usages. One way to fix this problem is putting either //no pmd or suppressing method for PMD.NonStaticInitializer.

Java doesn’t have a really nice way to initialize the collections. Because of this creating some constant collections, passing them to a method, or using them while unit-testing is kinda way too hard. For instance; you just need a 3 items in your list, but Java expects you to define in the following way:

If you want to file something away for later retrieval, it can be faster if you file it numerically rather than by a long alphabetic key. A hashCode is a way of computing a small (32-bit) digest numeric key from a long String or even an arbitrary clump of bytes. The numeric key itself is meaningless and the hashCode functions for computing them can look a bit insane. However, when you go to look for something, you can do the same digest calculation on the long alphabetic key you are looking for, and no matter how bizarre an algorithm you used, you will calculate the same hashCode, and will be able to look up numerically with it. Of course there is always the possibility two different Strings will have the same digest hashCode. However, even then, all is not lost; it greatly narrows down the search, hence speeding it up. A Hashtable goes a step further, scrunching down the hashCode even further to an even smaller number that it can use to directly index an array, usually by dividing it by some (ideally prime) number and taking the remainder.

I saw this introduction in one of the site that I was surfing. The main idea of hashing was exactly this. In Java 1.0.x and 1.1, String.hashCode function was working by sampling every nth character. However, this was slowing down the Hashtable lookup. With Java 1.2, function has been improved to multiply the result by 31 then add the next character in sequence. This was much slower, but much secure to avoid the collisions. For Object.hashCode things were almost same. Then Sun came up with a much wider spec which 1.4 implementation made sense after.