[jira] [Comment Edited] (HBASE-19746) Add default impl to Cell#getType

["Chia-Ping Tsai (JIRA)" <ji...@apache.org>]

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

Chia-Ping Tsai edited comment on HBASE-19746 at 4/22/18 8:25 AM:
-----------------------------------------------------------------

hi [~lars_francke] Thanks for the nice question.
{quote}So for 3.0 we remove the default implementation again?
{quote}
Not really. The API which will be removed in 3.0 is -Cell#getType- (typo...It should be Cell#getTypeByte). We have deprecated the Cell#getTypeByte and suggested user to implement the Cell#getType also in 2.0. Hence, we can remove Cell#getTypeByte in 3.0.
{quote}And you do this to not break API compatibility between 1.x and 2.x?
{quote}
Yep. this issue is to keep the bc of Public class (Cell).
{quote}As far as I understand the compatibility rules in the book (which I still have on my todo list to clarify) we don't guarantee any compatibility between Major releases. 
{quote}
IIRC, our rules to Public class is we must deprecate the API in a whole major release before we really remove them in next major release.  Also, we should introduce the replacement for deprecated APIs.
{quote}Otherwise how would we ever add new methods to interfaces for which we cannot provide a default implementation?
{quote}
Ya, we have discussed this issue before - how we keep the bc for the inheritance. see HBASE-19535. If we can introduce an annotation to say the bc of inheritance to specified Public class isn't guaranteed, our life will be more easier.  BTW, the BC is fine if the impl is from hbase.
{quote}If this is the case I'm -0 to include this. Doesn't this just shift the problem to the next version? 
{quote}
Not really. We create a room to remove the Cell#getType in 3.0.
{quote} There's nothing notifying implementors of the Cell interface of this new default method (unlike with @deprecated things)
{quote}
I expect that hbase user should check the doc of deprecated API to find out the replacement. The comment is shown below.
{code:java}
/**
 * @return The byte representation of the KeyValue.TYPE of this cell: one of Put, Delete, etc
 * @deprecated As of HBase-2.0. Will be removed in HBase-3.0. Use {@link #getType()}.
 */{code}
Of course, it would be better to have a more readable way to reminder user to use new APIs.
{quote}There's also nothing in the release notes and the Javadoc for getType also doesn't notify users about what's going to happen.
{quote}
You are right.  We make a considerable change to Cell APIs (RawCell, ExtendedCell, CelBuilder, and so on) but no fat docs are added. I can file a Jira to write the use case to hbase doc for the new usage of Cell.


was (Author: chia7712):
hi [~lars_francke] Thanks for the nice question.
{quote}So for 3.0 we remove the default implementation again?
{quote}
Not really. The API which will be removed in 3.0 is Cell#getType. We have deprecated the Cell#getTypeByte and suggested user to implement the Cell#getType also in 2.0. Hence, we can remove Cell#getTypeByte in 3.0.
{quote}And you do this to not break API compatibility between 1.x and 2.x?
{quote}
Yep. this issue is to keep the bc of Public class (Cell).
{quote}As far as I understand the compatibility rules in the book (which I still have on my todo list to clarify) we don't guarantee any compatibility between Major releases. 
{quote}
IIRC, our rules to Public class is we must deprecate the API in a whole major release before we really remove them in next major release.  Also, we should introduce the replacement for deprecated APIs.
{quote}Otherwise how would we ever add new methods to interfaces for which we cannot provide a default implementation?
{quote}
Ya, we have discussed this issue before - how we keep the bc for the inheritance. see HBASE-19535. If we can introduce an annotation to say the bc of inheritance to specified Public class isn't guaranteed, our life will be more easier.  BTW, the BC is fine if the impl is from hbase.
{quote}If this is the case I'm -0 to include this. Doesn't this just shift the problem to the next version? 
{quote}
Not really. We create a room to remove the Cell#getType in 3.0.
{quote} There's nothing notifying implementors of the Cell interface of this new default method (unlike with @deprecated things)
{quote}
I expect that hbase user should check the doc of deprecated API to find out the replacement. The comment is shown below.
{code:java}
/**
 * @return The byte representation of the KeyValue.TYPE of this cell: one of Put, Delete, etc
 * @deprecated As of HBase-2.0. Will be removed in HBase-3.0. Use {@link #getType()}.
 */{code}
Of course, it would be better to have a more readable way to reminder user to use new APIs.
{quote}There's also nothing in the release notes and the Javadoc for getType also doesn't notify users about what's going to happen.
{quote}
You are right.  We make a considerable change to Cell APIs (RawCell, ExtendedCell, CelBuilder, and so on) but no fat docs are added. I can file a Jira to write the use case to hbase doc for the new usage of Cell.

> Add default impl to Cell#getType
> --------------------------------
>
>                 Key: HBASE-19746
>                 URL: https://issues.apache.org/jira/browse/HBASE-19746
>             Project: HBase
>          Issue Type: Sub-task
>            Reporter: Chia-Ping Tsai
>            Assignee: Chia-Ping Tsai
>            Priority: Critical
>             Fix For: 2.0.0
>
>         Attachments: HBASE-19746.v0.patch, HBASE-19746.v1.patch, HBASE-19746.v1.qa.patch
>
>
> Noticed this issue when migrating the app to branch-2.
> {{Cell}} is IA.Public so it should obey our compatibility rules. Not sure whether any related discussion had be in HBASE-19112. It worthwhile, however, to raise this issue again.
> FYI [~anoopsamjohn] [~ram_krish] [~stack]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)