JCache: hit and miss counter fail TCK tests for noop EntryProcessor operations

[cruftex]

With version 1.4 no hit or miss is counted, for a no operation EntryProcessor. This is a violation of the (current) JCache TCK, however, in our opinion it is correct, since with 1.4 the entry is never touched. Details:

The JCache TCK makes assumptions about the Hit and Miss statistics counters when an entry processor is used. The underlying assumption is, that a cached entry is always accessed.

The comment in the TCK reads:

The lookup and locking of the key is enough to invoke the hit or miss. No
Cache.Entry or MutableEntry operation is required.

The relevant TCK tests are:

• CacheMBStatisticsBeanTest.testCacheStatisticsInvokeEntryProcessorNoOp()
• CacheMBStatisticsBeanTest.testCacheStatisticsInvokeEntryProcessorGet()
• CacheMBStatisticsBeanTest.testCacheStatisticsInvokeEntryProcessorUpdate()

For example the sequence:

    // increase put counter
    cache.put(1l, "Sooty");

    //existent key. increase hit counter even though this entry processor does not call anything
    cache.invoke(1l, new NoOpEntryProcessor<Long, String>());
    cache.invoke(1l, new NoOpEntryProcessor<Long, String>());

    //non-existent key. increase miss counter
    cache.invoke(1000l, new NoOpEntryProcessor<Long, String>());

Starting in version 1.4 cache2k will not access the cache content, when no operation is done or it is only a write operation. With this optimization there is actually no way to find out whether its a hit or a miss, hence, there is no way to update the counters accordingly.

This optimization is IMHO legal with respect to the specification. The JCache TCK is asserting a behavior that is not specified. The Spec says the contrary (EntryProcessor javadoc):

Implementations may execute {@link EntryProcessor}s in situ, thus avoiding
locking, round-trips and expensive network transfers.