1

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?

KoichiSenada
  • 11
  • 1
  • 1
    Possible duplicate of [How to properly deprecate methods in Java?](https://softwareengineering.stackexchange.com/questions/218570/how-to-properly-deprecate-methods-in-java) – gnat Jun 21 '17 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? – KoichiSenada Jun 25 '17 at 16:05

1 Answers1

5

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.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
  • 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. – KoichiSenada Jun 25 '17 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. – KoichiSenada Jun 25 '17 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. – KoichiSenada Jun 25 '17 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. – KoichiSenada Jun 25 '17 at 16:28