Mapping back to the real world

Having briefly explored Hazelcast's distributed capabilities via a test console, let's have a look at how we are more likely to interact with a cluster in the real world. Let's create a new SimpleMapExample class with a main method to spin up and manipulate a named distributed map called capitals. Hazelcast refers to these named collections as a namespace and must be uniquely named across the cluster.

import com.hazelcast.core.Hazelcast;
import com.hazelcast.core.HazelcastInstance;
import java.util.Map;

public class SimpleMapExample {
  public static void main(String[] args) {
    HazelcastInstance hz = Hazelcast.newHazelcastInstance();

    Map<String, String> capitals = hz.getMap("capitals");
    capitals.put("GB", "London");
    capitals.put("FR", "Paris");
    capitals.put("US", "Washington DC");
    capitals.put("AU", "Canberra");

    System.err.println(
      "Known capital cities: " + capitals.size());

    System.err.println(
      "Capital city of GB: " + capitals.get("GB"));
  }
}

As before, we should see various logging entries on the startup as well as the fun fact outputs; confirming we persisted into and retrieved from the map programmatically. We can also use this example in conjunction with our TestApp console from the previous section and interact with the new map capitals. To do this, we will need to switch namespaces from within the console before interacting with the map. Remember to make sure they have formed a cluster when using the console if you closed it since the previous example.

hazelcast[default] > ns capitals
namespace: capitals

hazelcast[capitals] > m.get GB
London

As with other implementations of Java maps, if we are creating our own objects for use within a Hazelcast map, we will need to consider the use of the custom equals() and hashCode() methods; however, it is the serialized binary form of the object that is used instead of these custom methods when the object is used as a key to a Hazelcast map entry.