[
https://issues.apache.org/jira/browse/OAK-11791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18004136#comment-18004136
]
Thomas Mueller commented on OAK-11791:
--------------------------------------
I'm not quite sure what the goal of this issue is... what is the real problem?
Is it that we want to remove the Guava dependency? Then we would need to remove
the Guava interfaces as well, right?
> Gradually replace Guava Cache by javax.cache interfaces
I would say, the goal is "remove the Guava Cache dependency"? Do we strictly
need the javax.cache interfaces, or are we OK with just removing Guava?
(Replacing it with the caffeine cache, with it's own API, is also achieving
that...)
> 1. CacheLIRS implements the Guava caching interfaces, but does not use any
> Guava implementation code.
Yes.
> 2. We could move CacheLIRS code into an internal class, and let CacheLIRS
> still use Guava cache interfaces.
This I don't understand... CacheLIRS is already an "internal class" in my view.
And we do want to get rid of the Guava cache interfaces?
> 3. Then implement a new class bases on javax.cache interfaces
That would be an option, but I'm not sure it's strictly necessary... It would
simplify moving our code to eg. the caffeine cache.
https://github.com/ben-manes/caffeine - that I think would be useful. But maybe
we can directly migrate to that?
> For existing APIs, the main differences appear to be thrown Exceptions and
> return values (boolean vs values)
Yes. Also, multi-threading, in my view.
There are some usages of the Guava cache that are a bit hard to migrate... e.g.
the usages in the elastic module.
> Gradually replace Guava Cache by javax.cache interfaces
> -------------------------------------------------------
>
> Key: OAK-11791
> URL: https://issues.apache.org/jira/browse/OAK-11791
> Project: Jackrabbit Oak
> Issue Type: Task
> Reporter: Julian Reschke
> Priority: Major
>
> 1. CacheLIRS implements the Guava caching interfaces, but does not use any
> Guava implementation code.
> 2. We could move CacheLIRS code into an internal class, and let CacheLIRS
> still use Guava cache interfaces.
> 3. Then implement a new class bases on javax.cache interfaces
> 4. Gradually migrate uses of the Guava Cache interfaces to the javax.cache
> interfaces and the new implementation
> 5. When done, remove old code
> For existing APIs, the main differences appear to be thrown Exceptions and
> return values (boolean vs values)
> The main issue seems to be the complicated way to obtain statistics, and the
> fact the way we expose cache stats in the DocumentNodeStoreService.
> [~thomasm] - what do you think?
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
