[jira] [Commented] (OAK-8702) deprecate Guava based APIs in o.a.j.o.cache

["Julian Reschke (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/OAK-8702?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16954464#comment-16954464 ] 

Julian Reschke commented on OAK-8702:
-------------------------------------

Proposal for deprecation

- we won't be able to {{@deprecate}}, but we can update the javadoc to tell people not to use this outside Oak
- additionally, we can add deprecation logging when the call stack shows that {{CacheLIRS}} was constructed from a "foreign" package



>  deprecate Guava based APIs in o.a.j.o.cache
> --------------------------------------------
>
>                 Key: OAK-8702
>                 URL: https://issues.apache.org/jira/browse/OAK-8702
>             Project: Jackrabbit Oak
>          Issue Type: Technical task
>          Components: core-spi
>            Reporter: Julian Reschke
>            Assignee: Julian Reschke
>            Priority: Major
>         Attachments: cache-removal.diff
>
>
> There are multiple classes here; but it seems the most important one is {{CacheLIRS}}, where the other ones are related to that.
> {{CacheLIRS}} implements the Guava {{Cache}} API.
> In a perfect world, we would implement new variants which do not rely on that API but are "sufficiently" compatible. Unfortunately, that would mean adding own APIs that replecate the Guava API. Furthermore, due to the way the caches work, there are quite a few support API (Loader, Weicher, Stats etc) that would need to be added as well.
> The classes are currently used in three other parts of Oak, and hopefully not anywhere else. The best way forward seems to me to leave them untouched, but stop exporting the packages. Other users inside Oak would need to embed copies of the ~5 classes for now.  [^cache-removal.diff] demonstrates how that would work.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)