Serialization and classes

One issue that we do introduce when using the client driver is that while our cluster can hold, persist, and serve classes, it doesn't have to and might not actually hold the POJO class itself in its classpath; rather, a serialization of the persisted object. This means that as long as each of our clients holds the appropriate class in its classpath, we can successfully serialize (for persistence) and de-serialize (for retrieval) the objects, but our cluster nodes can't. You can most notably see this when we try to retrieve entries via the TestApp console for custom objects stored to the cluster by a client, as this will produce ClassNotFoundException.

The process used to serialize objects to the cluster starts by checking whether the object is a well-known primitive-like class (String, Long, Integer, byte[], ByteBuffer, and Date); if so, these are serialized directly. If not, Hazelcast next checks whether the object implements com.hazelcast.nio.DataSerializable...