There is that @Deprecated annotation which suits well for Java libraries. A minor release change would not break an existing code if a deprecated library method remains. The library compilation will not report deprecated code use warnings because the library itself does not call its own deprecated methods.

But what if the deprecated method is in a monolithic server class code, where a highly reused code migration is a slow process executed by a number of developers sequentially?

Let us say, we have an original method that is used in multiple parts of server code for multiple clients and one day we come up with a decision to introduce a new method to replace it. But there will still remain some uses of the original method in our server code because the code migration is a long incremental process. Should we mark the original method with the @Deprecated annotation immediately?

The pros are that future implementations will avoid using it because the method is marked with the annotation and thus with strikethrough line style in IDE.

The cons are that remaining implementations also become marked with strikethrough line style as well, and the Java compiler reports warnings about the remaining uses, until all of the assigned developers update their respective parts of the monolithic code to get rid of using the deprecated method.

So, what would be the best method deprecation approach for a monolithic application with slow code migration process?

  • 1
    Possible duplicate of How to properly deprecate methods in Java?
    – gnat
    Commented Jun 21, 2017 at 14:56
  • Thank you, @gnat So their solution is to apply the @Deprecated annotation along with enabling compilation failing on warnings and then suppressing deprecation method usage warnings with @SuppressWarnings( "deprecation" ) annotation? Is that the best solution for a monolithic multi-module project code as well? Commented Jun 25, 2017 at 16:05

1 Answer 1


In my opinion, whether a code base is monolithic or distributed, or whether migration is expected to be slow or fast, has no bearing on using @Deprecated. The only relevant distinction is whether you control the entire code base or not.

Rationale: deprecation is a concept that was invented to provide an incentive to migrate away from certain code without immediately breaking its current users. If people take a long time to follow the incentive, they will have to live with warnings for a long time, but not with errors, and that is exactly the trade-off that the annotation is supposed to provide. Simultaneously, people who migrate quickly will be rewarded with "green" builds earlier, which provides the incentive that we wanted.

Whether the code base is monolithic or distributed is also irrelevant. The only difference this makes is whether the resulting warnings occur in one project or distributed across many projects. For any organization that pursues a comprehensive I.T. strategy, this should not make a big difference.

What is highly relevant is whether your code is used only by yourself, or whether there are external users (in the extreme case, potentially any internet user). This makes a huge difference: if you do not control the behaviour of the users of your code, you can never be sure about the cost that deprecating or removing old code would have, which requires you to be much, much more conservative about removing code. If the only users of the code in question are answerable to the same management that decides about the modernization, then you can consider the effort of migrating all clients and the benefits of improving the libraries at the same time, which has the potential of much better-informed decisions.

  • Thank you, @kilian-foth I suppose that actually there is a difference beween monolithic and distributed projects. The difference is whose responsibility that is to refactor the depending logics code. Commented Jun 25, 2017 at 16:21
  • Distributed modules project has modules that are compiled and deployed separately. Deprecating a method would keep the infrastructure logics module "green" built and deployed since it does not use its own deprecated method in its own code. Then a business logics module compilation will throw the warning and its developers will have to decide what to do about it. Commented Jun 25, 2017 at 16:26
  • But a multi-module monolithic project is build is "green" just as long as each of its modules is built "green". Thus handling the deprecation warnings is the responsibility of the infrastructure logics development team. Commented Jun 25, 2017 at 16:28
  • That is why I am looking for the best solution that would fit a Java Maven multi-module project case where each module has its own development team with their specific respective responsibilities, yet the project is being compiled and deployed at once as a whole. There is a strong wish to keep all the builds "green", but an industry practices research would assist greatly at deciding about that wish. Commented Jun 25, 2017 at 16:28

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.