I agree on this one.
Whenever we deprecate a method or a feature we should add a comment that
explains the new API or why the feature was removed without replacement.
Enforcing this information through checkstyle makes sense as well, IMO.
Cheers, Fabian
2016-11-23 4:42 GMT+01:00 sjk <shijinkui...@163.com>:
> Hi, all
>
> Let’s have look at Checkpointed interface below. It declared deprecated
> but have no detail for why, when and how replace this function. It’s a big
> trouble for the users.
>
> @Deprecated
> @PublicEvolving
> public interface Checkpointed<T extends Serializable> extends
> CheckpointedRestoring<T> {
>
>
> I think we should have more detail: when give up, who replace it, why
> deprecated.
>
> For Java code, add detail deprecated reason in code annotations.
> For Scala code, replace Java annotation @Deprecated(,,) with Scala
> annotation @deprecated, such as
> @deprecated(message = "the reason", since = "when fully give up”)
>
> Add this rule to customized checkstyle plugin of maven and SBT.
>
> Best regard
> -Jinkui Shi
