[
https://issues.apache.org/jira/browse/HBASE-15982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15420658#comment-15420658
]
Andrew Purtell commented on HBASE-15982:
----------------------------------------
bq. I still want to use Guava as our long term Service interface, because the
interface it pretty well defined. However, maybe we can wrap it so that RE is
not exposed to it directly.
It might be difficult indeed to use Guava as the basis for our Service
interface if it embeds a requirement for a Category X dependency.
We harmonize on Guava 14 for internal builds after finding something that works
across HDFS, HBase, Hive, Spark, and others. It's easy to revert the
jsr305-findbugs ban on an internal build but that won't be a workable solution
upstream.
> Interface ReplicationEndpoint extends Guava's Service
> -----------------------------------------------------
>
> Key: HBASE-15982
> URL: https://issues.apache.org/jira/browse/HBASE-15982
> Project: HBase
> Issue Type: Bug
> Reporter: Andrew Purtell
> Fix For: 2.0.0, 1.4.0, 0.98.22
>
>
> We have Guava's Service leaking into the LimitedPrivate interface
> ReplicationEndpoint:
> {code}
> public interface ReplicationEndpoint extends Service,
> ReplicationPeerConfigListener
> {code}
> This required a private patch when I updated Guava for our internal
> deployments. This is going to be a problem for us for long term maintenance
> and implenters of pluggable replication endpoints. LP is only less than
> public by a degree. We shouldn't leak types from third part code into either
> Public or LP APIs in my opinion. Let's fix.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
