Hash code is the crucial thing in hash-based algorithms like those used in hash maps and all problems come from that simple fact. Its efficiency is as important as the efficiency of the hashing algorithm itself. Let’s talk about those problems and how to solve them.

Why hash code can cause a problem?

The main problems are:

1. Implementation determines the collision probability. This is an important factor and people tend to forget or underestimate it.
2. hashCode() should be implemented together with equals(Object) method as they are used jointly. The perfect implementation of those methods should correspond to each other e.g. use the same fields/methods and the same precedence.
3. You can easily forget to modify those two methods when you add a new field or modify it partially. This can sometimes break the correctness of the program. Of course, beside the case when you don’t want to use the new fields for objects comparison and hashing.

Simple hash collision examples

Here is my list of simple hash collisions (based on OpenJDK 11):

Welcome back to Hash Code miniserie where you can read how the hash codes (non-cryptographic hashing algorithms) and hash collections work in different programming languages. This time let’s take a look under the hood of Java’s collections and Strings. How hash codes are generated for them? Let’s check it out.

Arrays

Arrays in Java do not provide its own hashCode() implementation - it uses Object default which can cause a lot of error as hash depends on reference (an instance), not on its value. Java also provides better implemenation via Arrays helper class. Let’s take a look into the code:

Welcome to the first article of the Hash Code miniserie where you can read how the hash codes (non-cryptographic hashing algorithms) and hash collections work in different programming languages. Every software engineer uses hash collections like Python’s dictionary, Java’s hash map or C++’s unordered map. You get them to know pretty early in your learning path as they are key data structures to solve many problems effectively but are you sure that you know them well? In this miniserie, I will shed some light on this subject.

Is Kotlin just a beta version of Java and is it going to be superseded by Java and die? Or, is Java just trying to catch up from a better language but it will be never able to do this? Let’s check what is going on there!

From the birth of Kotlin to the present day

Java 8 was a big deal when it was released in March 2014. Lambdas and stream API enabled thousands of developers to start writing in a more functional style without boilerplate code as they could do before with Guava library. The first official Kotlin 1.0 release was in February 2016 between Java 8 and 9 releases (September 2017) and Kotlin already had Java 8 features (and many more) from day one.

Lombok is a Java library that generates boilerplate code for you during the compilation. You probably use it or at least heard how it can clean the code with annotations like @Data or @Value. So I am not going to write yet another article on how to use the most popular annotations. I am going to show you one of the two most underrated features in Lombok - @Cleanup.

@Cleanup

It is just (or maybe even) an alternative to try-with-resource introduced in Java 7. Wait. What? In Java 7? When was that? On July 28, 2011. Why am I writing about alternative to feature introduced natively in Java almost eight years ago? We will get back to it soon. Let’s see a simple example first. Copy input stream into output stream with Lombok: