org.jivesoftware.util.cache.Cache has different characteristics when HZ clustered

When running in the old-style Coherence cluster, or non-clustered, a Cache object will happily take a null key (when non-clustered, it’s backed by DefaultCache, a wrapper around a plain-old HashMap).

Unfortunately, the Hazelcast backed Cache will not take a null key;

java.lang.NullPointerException: Null key is not allowed!

at com.hazelcast.util.Preconditions.checkNotNull( ~[?:?]

at ~[?:?]

at org.jivesoftware.openfire.plugin.util.cache.ClusteredCache.get(ClusteredCache.j ava:92) ~[?:?]

at org.jivesoftware.util.cache.CacheWrapper.get( ~[openfire.jar:?]

I think that the clustered and non-clustered maps should be consistent; I’m happy to submit a patch request to DefaultCache to reject null keys/values just like the Hazelcat map, if it would (in principle) be accepted.

OK, so it’s a bug in my code that’s triggered this, I just would have found it quicker had the behaviour been consistent between the two Cache implementations.


That’s enough of an edge case for me to assume that those (third party) implementations that make use of null-keys are very few in number. I’d prefer consistency, and would welcome a pull request.

I’ve created this issue in our bugtracker for this: [OF-1156] Cache implementations should have consistent behavior regarding null keys - IgniteRealtime JIRA

Thanks for the PR ( OF-1156: Be consistent with the contents of DefaultCache with the HZ cache by GregDThomas · Pull Request #609 · ignitere… )

Your fix has been merged, and should be part of the 4.1.0 release.