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