To respond to your observations, in a back-stepping fashion:
4. we'll will probably use internally (shouldn't have made it in with the diff), until a complete fix is made.
My reasoning for using that flag, though, was that it is always set to true, and not accessible to users outside the JCS interface to the cache. It didn't seem terribly public.
Granted, that was making an architectural change, outside the proper place. The flag should probably be put on the object that wraps the key-value pair (CacheElement).
3. I'll send the test files, the defrag test we're using. It's not a direct unit test, since all of the issues we encountered while rewriting the defrag was through threading. Pretty hard to write it that way. But we probably should write a unit test around
I have a whole philosophical argument against writing unit tests against private methods by making them protected involving software api contracts, but I won't get into that...
2. Might have missed a few places for that. Ideally, it's really only required for messages that append things (saves the appending) since log ignores are pretty fast in themselves. I'm not against the checks being put in there. It's not really the performance bottleneck here.
1. Custom serialization is already in the Java language spec. The users (i.e. the developers writing objects to be put in the cache) should be use Externalizable if they want something different (more compact, different initialization, etc).
Although, I suppose the argument could be made for an XML Serialization, but I'm not really sure there's a value in using it in the context of object caching. That should again be accomplished through Exteralizable though.
Either way. The pattern for using the Serializers wasn't clear, since was half implemented. I was just replacing the private methods of IndexedDisk with the serializer. It's a step towards using the Serializers, and can be more easily refactored in the future, when the custom serializer feature is fully implemented.