storeAsBinary in Infinispan was designed with the following purposes in mind, in order of importance:

1) Performance. Prevent serialising/deserializing an entry multiple times (e.g., to write through to disk, to replicate over the network, concurrent threads needing to read the object representation).

2) Classloader isolation (as Galder mentioned). This became a secondary purpose of this feature (originally observed as a side-effect). Enhanced by allowing storeKeyAsBinary and storeValueAsBinary options for more fine-grained control of this behaviour.

Now lets consider what JSR 107 needs. Similarly named, the feature in JSR 107 serves a completely different purpose, and this is referential integrity. Think database-style isolation (repeatable read, etc) where concurrent threads holding object references to the same value, and mutating the same value, are not visible until a commit.

I originally thought that Infinispan's storeAsBinary can be used for this, but apparently not without some additional changes/tweaks. Maybe we need:

1) A new config option for this behaviour. <storeAsBinary defensive="true" /> ?
2) If enabled, maybe use a subclass of MarshalledValue (DefensiveMarshalledValue?) that always stores a byte[] and never caches the object representation?