org.infinispan.marshall.Externalizer
One of the key aspects of Infinispan is that it often needs to marshall/unmarshall objects in order to provide some of its functionality. For example, if it needs to store objects in a write-through or write-behind cache store, the objects stored need marshalling. If a cluster of Infinispan nodes is formed, objects shipped around need marshalling. Even if you enable lazy deserialization, objects need to marshalled so that they can be lazily unmarshalled with the correct classloader. Using standard JDK serialization is slow and produces payloads that are too big and can affect bandwidth usage. On top of that, JDK serialization does not work well with objects that are supposed to be immutable. In order to avoid these issues, Infinispan uses JBoss Marshalling for marshalling/unmarshalling objects. JBoss Marshalling is fast , provides very space efficient payloads, and on top of that, allows users to construct objects themselves during unmarshalling, hence allowing objects to carry on being immutable. Starting with 5.0, users of Infinispan can now benefit from this marshalling framework as well, and they can provide their own implementations of the Externalizer interface in order to define, how a particular object type needs to be marshalled or unmarshalled. It's common practice to include Externalizer implementations within the classes that they marshall/unmarshall as public static classes. To make Externalizer implementations easier to code and more typesafe, make sure you define type as the type of object that's being marshalled/unmarshalled. You can find plenty of examples of Externalizer implementations in the Infinispan code base, but to highlight one, check the Externalizer implementation for {@link org.infinispan.remoting.transport.jgroups.JGroupsAddress} in{@link org.infinispan.remoting.transport.jgroups.JGroupsAddress.Externalizer}{@link AbstractExternalizer} provides default implementations for some of the methodsdefined in this interface and so it's generally recommended that implementations extend that abstract class instead of implementing {@link Externalizer} directly.
@author Galder Zamarreño
@since 4.0