I have a CacheLoader that injects EmbeddedMetadata so that I can specify the lifetime of the newly loaded entry. EmbeddedMetadata is supposed to be used when only lifespan or maxIdle are required (I only need lifespan); this works because the lifespan (and maxIdle) information is copied into the internal node itself - no extra Metadata object is allocated.

The InternalNode has several implementations, each used for the different combination of lifespan and maxIdle. Let's proceed with MortalCacheEntry (lifespan only). Its metadata-aware sibling is MetadataMortalCacheEntry. Each of those has a special code path in EntryWrappingInterceptor for updates of metadata. This path is chosen not based on the type of the InternalEntry (so that it can also work for new entries, where there's no internal entry object yet) but instead the decision is made in InternalEntryFactoryImpl.isStoreMetadata() based on the type of the Metadata object - if it returns true, then the path for MetadataMortalCacheEntry is used. This path then inspects the actual type of the internal entry object so that can update it accordingly.

Enter Functional API.

After I return EmbeddedMetadata from the CacheLoader, the expiration parameters are updated just fine - the EmbeddedMetadata is recognized and a MortalCacheEntry is created with the expected lifespan. Then, when we use

EntryView.WriteEntryView.set(value, params...)

to update the metadata (which is the only way to do that in Functional API), the Metadata object in the entry gets replaced with an instance of MetaParamsInternalMetadata. This makes isStoreMetadata() return true (because the Metadata object is no longer EmbeddedMetadata). EntryWrappingInterceptor then goes into the metadata-aware code path where MortalCacheEntry is not handled (MetadataMortalCacheEntry is instead) and the metadata update is not performed at all.