[
https://issues.apache.org/jira/browse/OAK-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372825#comment-16372825
]
Davide Giannella commented on OAK-7225:
---------------------------------------
[~reschke] I've replaced the exposed part of guava with the OOTB java bits. The
changes are trivial and you can review them in [^OAK-7225-0.diff] or on the
[git
branch|https://github.com/davidegiannella/jackrabbit-oak/compare/trunk...davidegiannella:OAK-7225?expand=1].
I've looked a bit more into the usages of guava and potential replacement. The
trickiest part is the replacement of the
[ThreadFactoryBuilder|https://github.com/davidegiannella/jackrabbit-oak/blob/OAK-7225/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/atomic/AtomicCounterEditorProvider.java#L175]
which provides a handy way to name threads in the Executor. It's possible to
replace it though with a simple custom implementation extending the default
implementation in java.
Most of the guava code in the Atomic counter I found could be replaced:
checkNotNull vs Objects.requireNonNull, ImmutableSet etc vs
Collections.unmodifiable()... But I don't actually know if we could get rid of
the whole Guava thing for the whole functionality. And it goes beyond the scope
of this issue.
Thoughts?
> Replace AtomicCounter Supplier
> ------------------------------
>
> Key: OAK-7225
> URL: https://issues.apache.org/jira/browse/OAK-7225
> Project: Jackrabbit Oak
> Issue Type: Sub-task
> Components: core
> Affects Versions: 1.4.0, 1.6.0
> Reporter: Davide Giannella
> Assignee: Davide Giannella
> Priority: Major
> Attachments: OAK-7225-0.diff
>
>
> In the
> [AtomicCounter|https://github.com/apache/jackrabbit-oak/blob/7a7aa1e5d4f53f5bfb410f58264c237b288f5c74/oak-core/src/main/java/org/apache/jackrabbit/oak/plugins/atomic/AtomicCounterEditorProvider.java#L121]
> we use guava's Supplier which should be trivially replaced by the JDK8
> [java.util.function.Supplier|https://docs.oracle.com/javase/8/docs/api/java/util/function/Supplier.html].
> In case of backports to Oak 1.4, and therefore Java7 it should be possible to
> workaround the FunctionalInterface with a utility class.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
