hbase-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chia-Ping Tsai (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (HBASE-19595) explicitly discourage public user from creating their Public pojo
Date Fri, 22 Dec 2017 11:37:00 GMT

     [ https://issues.apache.org/jira/browse/HBASE-19595?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel

Chia-Ping Tsai updated HBASE-19595:
    Fix Version/s: 2.0.0

> explicitly discourage public user from creating their Public pojo
> -----------------------------------------------------------------
>                 Key: HBASE-19595
>                 URL: https://issues.apache.org/jira/browse/HBASE-19595
>             Project: HBase
>          Issue Type: Task
>            Reporter: Chia-Ping Tsai
>            Priority: Blocker
>             Fix For: 2.0.0
> HBASE-19496 make both of ReplicationLoadSink and ReplicationLoadSource be IA.Public since
they are exposed by other Public class (ServerMetrics). Currently, their constructor are annotated
with IA.Private to discourage user from creating their ReplicationLoadSink and ReplicationLoadSource.
However, that is too implicit as users have to trace the source code to "see" the warnings.
> I believe that many pojo in hbase have same issue. We have some kinds of coding style
to warn user not to create their Public pojo.
> # IA.Private constructor. for example, ReplicationLoadSink and ReplicationLoadSource
> # pure interface. for example, TableDescriptor, ColumnFamilyDescriptor, ClusterMetrics
> # final class and package private constructor. for example, CacheEvictionStats
> All of them have pros and cons. #1 is a simple solution but it is too implicit for user.
#2 will cause the BC issue (see HBASE-19535). #3 is good solution to prevent user from using
the constructor or extending the pojo. However, it may limit us also. (mockito or extend the
pojo internally)
> Any suggestions?

This message was sent by Atlassian JIRA

View raw message