Add note to documentation when using Spring integration and Optional values

The chapter on null values states that:

In case the loader returns null and this should not lead to an exception the following options exist: Always return a non-null object and include a predicate for the null case, use a list or Java 8 Optional.

However, when using the Spring Framework integration and values are of class Optional, since Spring unwraps the value in CacheAspectSupport, an NPE will be thrown unless permitNullValues is set to true.

I think this is worth mentioning in the Spring chapter. Let me know what you think. I can open a PR to add this to the docs. I haven’t done so because I don’t know if https://github.com/cache2k/cache2k/issues/135 will conflict with Spring or will make that consideration unnecessary.

[cruftex]

So in Spring permitNullValues(false) would be an optimisation of sorts?

Using permitNullValues(true) and using the null support in cache2k is the optimization for Spring, because that means there is no additional object wrapper needed.

Just looking on cache2k itself there is no runtime difference whether this is enabled or not. The flag is present to be aware of the difference in behavior. Historically null support was always enabled. But analyzing code using the cache revealed that developers think that null means no cached value is present. Typical cache aside code looked like:

  V value = cache.get(key);
  if (value == null) {
    value = ....;
    cache.put(key, value);
  }

As soon null is a legal value in the cache, that code is wrong.

With the default settings cache2k is compatible with other caches, w.r.t. null. But if you want it and know what you are doing, you can enable it.

[cruftex]

Releasing 1.4 and closing this issue, in the hope that nothing is left to do. Please feel free any time to comment here or raise another issue if there is still a problem.