cshannon commented on code in PR #3080:
URL: https://github.com/apache/accumulo/pull/3080#discussion_r1026319676
##########
core/src/main/java/org/apache/accumulo/core/data/Mutation.java:
##########
@@ -1501,42 +1491,36 @@ public int size() {
}
/**
- * Add a new element to the set of peers which this Mutation originated from
+ * Non-functional API; do not use
*
- * @param peer
- * the peer to add
* @since 1.7.0
+ * @deprecated old, no longer functional API for replication feature removed
in 3.0
*/
+ @Deprecated(since = "3.0.0")
Review Comment:
I'm definitely in favor of removal in 3.0.0 since it's a major version
update and that is the time to make API changes. If we had to pick one of the
other 2 then I'd prefer UnsupportedOperationException over NOOP, but removal is
the best to me.
Normally when you mark something as deprecated it is still functional but
just not recommended and the plan is to remove it in the future (but still
currently works), so marking it in 2.1.1 as deprecated makes sense as the code
will still be there.
However for version 3.0.0, if all the functionality has been removed, I see
no point of leaving in the methods. As you pointed out already,
UnsupportedOperationException is not great because instead of catching the
error early you now delay it to runtime. NOOP to me is the worst option as that
is very misleading to leave methods around that don't do anything and could
cause compile time issues later if you wanted to remove it. Someone might not
pay attention and miss the deprecation warnings and now when they update the
methods just don't do anything with no obvious warning or error, which could be
even worse than a runtime error.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
