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 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
  • 110,899