ben-manes / caffeine / #5511

100%

master: 100%

push

github

Fix JCache zero update-expiry divergence across the write paths

Per ExpiryPolicy.getExpiryForUpdate (JSR-107 1.1.1), a Duration.ZERO update means
the entry "is considered immediately expired" -- it is updated, then expires --
unlike a zero creation expiry, where it "will not be added to the Cache". The
put-family paths (putNoCopyOrAwait, used by put/putAll/getAndPut) folded the update
case into the creation guard: they suppressed the UPDATED event and the put
statistic and removed the entry, while replace/getAndReplace/invoke correctly
published UPDATED, counted the put, and stored an immediately-expired entry. Split
the guard to suppress only on creation (expirable == null); a zero update-expiry now
stores the entry already expired (reaped on the next access, which publishes
EXPIRED), matching replace/getAndReplace/invoke.

Resolved against the live 1.1.1 spec, the reference implementation, and the
ecosystem: the side-effect behavior splits RI/Coherence/cache2k/Ehcache3 (store
immediately-expired, fire UPDATED, count the put) against Infinispan/Ehcache2/
Hazelcast (remove/suppress), 4-3, and the spec text plus the RI settle it. The TCK
passes either way -- it asserts only the end-state, not the event stream or the
statistics -- so a parity test (JCacheUpdateExpiryTest.writeOp_present_zeroUpdateExpiry
over put/putAll/getAndPut/replace/replaceConditionally/getAndReplace/invoke) pins
every update path to fire one UPDATED, count one put, and leave the entry absent.

Add /audit-jcache-conformance and .claude/docs/jsr107-conformance.md to make this
repeatable: fetch the spec (a Google Doc) live, map the RI/ecosystem sources, and
run the spec -> TCK -> RI -> ecosystem differential that catches the TCK-invisible
event/statistics divergences this class of bug lives in.

4032 of 4040 branches covered (99.8%)

4 of 4 new or added lines in 2 files covered. (100.0%)

8219 of 8219 relevant lines covered (100.0%)

1.0 hits per line