final fields cannot be modified, so why replicate them ?
However, static fields *should* probably be replicated, what is the current behavior ? Ben, Brian ?
Thanks for the quick answer.
Concerning final, I see that it makes no sense replicating final fields that point to immutable objects (e.g. Strings). But when the referenced object is mutable I might want to replicate changes to it, too.
Objects are mapped into the cache by reachability, but objects referenced by final fields aren't, so I have to do this manually.
I think I have seen that when I do a putObject(), fields containing Collections are replaced with AOP Proxies. This of course would be a problem with a final field; but why disallow it for other kinds of objects?
It is stated in the documentaiton that currently neither final, transient, or static fields are replicated.
To replicate static is really case dependent since it it a global variable. Question is then how do we store it internally if there are multiple POJOs stored in the cache? And this has implication such as region, etc.
As for final, I can make it configurable if there are enough use cases such that it can be treated as mutable.
Oh yes, the documentation makes it clear that those are not replicated; I was just curious about the reasoning behind that (a customer asked and I couldn't come up with entirely satisfactory answers).
For the static case, I agree that this shouldn't be the default. But as with final, in simple cases it could be desirable to have the option. As for how to store it, I think most people would expect that multiple POJOs shared the same static instance just as it would be without the cache. In my thinking, this wouldn't have to be handled differently from the case where many POJOs reference the same object non-statically. Are regions used for more than eviction? If not, I think the referencing POJOs could just be evicted as usual, and the sole static object instance could be kept somewhere else, separate from the regions containing the referencing POJOs (__internal__:<fully qualified class name>?).
But I'm just asking. "Nobody has needed it yet and it would need some more thought, so we are working on more pressing issues. If you think you need it, request the feature in JIRA and if enough people want it, we'll look into it" would be a perfectly satisfying answer for me. I just wanted to know if there are known reasons that make it (practically) impossible to support this.
Thanks for your comments.