Without an externalizer, the EntityKey class is serialized using standard java serialization into the Infinispan entry, and would introduce a dependency to OGM (up to possibly a specific version).

Since I agree with you, that's why I'm thinking about introducing the Externalizer: so that we can define e a format which suites us better, and possibly to consider version migrations without disruptions in data readability.

This issue was created after we discussed how it would be redundant to specify all column names over and over for each EntityKey as we do today; The proposal on the Infinispan mailing list is merely to be able - optionally - to take advantage of repetitions for immutable value objects, as we could share instances if we have a common registry controlled by the application, but an Externalizer which defines the serialization format - for example - as two Strings doesn't make long term storage harder, nor actually changes the internal data format, just saves memory.

As in my last post on the Infinispan thread, iff our custom Externalizer was used (which doesn't preclude using a simpler one), then we could apply some runtime performance tricks as well, like reference equality over equals. But again, the wire format and what would be eventually stored in CacheLoaders is independent from any OGM code.