Added ability to use Caffeine for Caching, which enables additional features like eviction, which is not supported by existing ConcurrentHashMap parseCache (#45)

[siddarthaboddu]

Issue: #45
This change is to provide clients option to use Caffeine with a pre configured max size, so that the parseCache does not grow indefinitely which were causing JVM high memory issues

Changes:

• Added CacheManager interface to be able to use ConcurrentHashMap or Caffeine for caching.
• Added ConcurrentHashMapCacheManager class which uses ConcurrentHashMap for caching, this will be default behaviour ensuring backward compatibility.
• Added CaffeineCacheManager which uses Caffeine for caching, and provides option to specify a max size of the cache.
• Minor update to the version from 1.1.1-SNAPSHOT to 1.1.2-SNAPSHOT

[jamsesso]

Nit, but this could have been:

  public JsonLogic() {
    this(new ConcurrentHashMapCacheManager<>());
  }

  public JsonLogic(final CacheManager<String, JsonLogicNode> parseCache) {
    this.parseCache = parseCache;

    // Add default operations
    addOperation(MathExpression.ADD);
    addOperation(MathExpression.SUBTRACT);
    // ...
  }

[jamsesso]

IMO this should live in your upstream project, not in the source of JsonLogicJava. I don't like the idea of bringing in a dependency for all consumers of this library that may not use it.

[jamsesso]

No need to touch this file anymore, there is a Github action that handles this all.

[verhas]

If I may add here what I think about this issue:

Handling the cache is a functionality that should not be in JsonLogic. It becomes more evident when someone wants to add a better cache, and it requires an external dependency. You do not want to add it. Then why do you add the ConcurrentHashMap? Why should it be concurrent? Does JsonLogic handle concurrency? (No, it does not.)

An application may need this functionality, but it has to handle caching with any cache solution, multi-threaded or not, according to its needs.

I would just delete the parseCache altogether and I would provide an API to

• parse a JSON
• evaluate a parsed JSON.

It is up to the application if it wants to do it in separate steps and set the parsed JSON aside wherever it wants.

This parseCache can cause issues. A Spring application cannot use JsonLogic as a singleton framework-managed resource because it will leak memory. In some applications, there may be millions of distinct JSONs, each used once and stored in the map. Instead, the application has to create a new instance every time. It is not a big deal, but it still shows that caching is a function that is not the core functionality of the library and, in my opinion, should be left for the application to implement whatever they want.