One issue we do introduce when using the thin 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; rather a serialization of the 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), but our cluster nodes can't. You can most notably see this if we try to retrieve entries via the TestApp console for custom objects, 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, Date); if so, these are serialized directly. If not, Hazelcast next checks to see if the object implements com.hazelcast.nio.DataSerializable and if so uses the appropriate methods provided to marshal the object. Otherwise...