Overriding equals and hashCode methods in Java

The default implementation of equals() method is provided by Object compares memory location and only return true if the reference variable is pointing to same memory. When overriding equals method, here are the rules that the equals method must obey:
  1. Reflexive: Object must equal to itself.
  2. Symmetric: if a.equals(b) is true and then b.equals(a) must be true.
  3. Transitive: if a.equals(b) is true and then b.equals(c) is be true, then c.equals(a) must be true.
  4. Consistent: multiple invocations of a.equals(b) consistently return true or false, provided no information used in equals comparisons on the objects are modified.
  5. Null comparison: if a.equals(null) should return false.

Step to override equals method

  1. Return true if they are having same address
  2. Return false if the reference object is null
  3. Check subclass or same class by instanceof method
  4. Type cast the object
  5. Compare individual attributes and should avoid NullPointerException
Suppose you are creating a Money class with currency and amount. You could possibly decide that two Money objects must be referring to the same money if they have exactly the same currency and amount fields.

Notice also how verbose Java is, even in an operation as basic as comparing Money for equality. I preferably use the JDK7’s Objects and Guava’s Objects as below:
The new edition of the code will become easier.

Equals and hashCode contract in Java

When using a hash-based Collection or Map such as HashSet, LinkedHashSet, HashMap, HashTable, or WeakHashMap…, the hashCode() of key objects that you put into Collection never changes while the object is in the collection.
For equals and hashCode contract, there are two ideas:
  1. If two objects are equal by equals() then their hashCode must be same.
  2. If two objects are having the same hashCode then it does not mean that both objets are equal by equals() method. They might be un-equal also, so their hashCode might be the same or different.


Java libraries at Google

Here's some things we might know java core libraries at Google.These might be useful for your projects.

  • Guava - java core libraries we find useful in Java projects
  • Dagger - simple & fast dependency injection without reflection
  • Guice - Dagger's reflectiony predecessor
  • Caliper - makes Java microbenchmarking less painful
  • The Auto project - simple, generated value types (AutoValue), factories (AutoFactory) and more
  • Jimfs - full-featured on-heap file system implementation (for java.nio.file)
  • Refaster - syntax-aware refactoring by example (coming soon)
  • Google's Java style guide
  • Square Open Source - Our best friends.


Parallel, Concurrent and Asynchronous Programming

Parallel Programming

In parallel programming, multiple calculations are executed simultaneously. The computations are typically CPU-intensive and perform either different operations on the same data set or perform the same operation on parts of a data set.

  • To be run using multiple processors
  • A problem is broken into discrete parts that can be solved concurrently
  • Each part is further broken down to a series of instructions
  • Instructions from each part execute simultaneously on different processors
  • An overall control/coordination mechanism is employed

Concurrent Programming

In concurrent programming, programs are designed as computations that interact. The computations may be executed on multiple threads, but also using just a single thread.

  • Multiple threads of control

A number of sequential programs programs work together to achieve a goal.

  • Inter-process Communication

Shared variables and Message passing

  • Synchronization
  1. Mutual exclusion

processes must execute their critical sections one at a time.

  1. Conditional synchronization

processes wait until a condition is true.

Asynchronous Programming

The term asynchronous is used when describing I/O operations that do not block a thread while waiting for completion.

It's common to look at asynchronous processes as non-blocking (the system won't lock up, will continue). Asynchronous programming was typically implemented using callbacks or events.