Java Deep

Pure Java, what else

Use Java annotation deprecated the right way

There is hardly anything more infuriating that seeing a method @Deprecated without a proper documentation. I feel lost. Should I still use the method? Probably that is not the intention of the developer, that is why he/she added the deprecation annotation. Should I use something else? So….

What are the rules using @Deprecated?

Rule #1: do Javadoc how not to

Whenever you deprecate a method create a JavaDoc that tells the programmer how not to use this method any more. Do not only say that “this method is deprecated, don’t use it”. That is exactly what the deprecation annotation and the JavaDoc @deprecated word says. There is no point to repeat it in English. The targeted audience is Java programmer, supposed to know what deprecation means.

Name the new methods, that replace the old one. (Use @link!) This may or may not be enough. The new method will have some documentation that explains how to use it. Do not repeat that (text or meaning) in the JavaDoc. Just do not repeat yourself, documentation should also be DRY. On the other hand you may want to describe how to replace the old call with the new one. You may give hint for the refactoring.

Rule #2: do not Javadoc how to

Remove the old JavaDoc documentation. Some may argue that users who maintain the legacy code may still need that. The fact is that they use an old version of the method in an old version of a library. The documentation in the old version is still there, frozen carved into stone (or rather carved into a release in the repository). The actual version that deprecates the method should not contain the outdated documentation. That would encourage the programmers to keep on using the method. There is one single way to use a deprecated method: not using it. JavaDoc should be current describing only that, as described above in rule#1.

Rule #3: no apology in JavaDoc

Do not explain in the JavaDoc why the method was deprecated. You are a responsible developer. This is your decision. You made your choice. Others have to live with it. Write a blog about the background of the architectural decision if you wish. It may be helpful, but JavaDoc is not the place for it.

Deprecated API JavaDoc is exclusively to explain how not to use.

The emphasis is on how. Not “why not to use it”.

Rule #4: do deprecate

If you feel like needing to deprecate a method: do it! If you are afraid of your users and you do not want to make their life miserable deprecating some method this decision will make your life miserable instead. Do all measures to have an API that will not need deprecation so long as long possible. But if ever something needs to be deprecated: throw it right away. Do not feel guilty why you did not see the future when the api was designed. None of us sees the future perfect. After all, life would be boring knowing the future.

If you are interested on opinions about this topic on stakcoverflow visit the linked page. Or just start a flame war, if you wish, here. I am totally trollerant.

About these ads

6 responses to “Use Java annotation deprecated the right way

  1. Hubertus Bigend February 10, 2014 at 10:50 am

    As to rule #2: Sounds correct, in theory, but in real life, one day a reason for updating a library comes up, and shortly thereafter a different reason comes up for looking into a different piece of code, and then there’s that call to a now-deprecated method that doesn’t even say what it’s doing anymore. Just because a method has been deprecated you shouldn’t impose unnecessary difficulties on people who still use it for whatever reason. A reason that might even be sensible ;-)

    Like

    • Peter Verhas February 10, 2014 at 2:42 pm

      If there is difference between theory and real life, then probably there is some problem with the theory. Or, for that matter, with the real life.

      First of all: the documentation is still there in the old version of the library. Have a look at that.

      Second: there is a working code that should fairly explain the usage of the method. If it does not, then this is not the lack of JavaDoc of the deprecated method the difficulty but rather the non clean code.

      Finally: if I, as a developer of a library encourage the users (my customers) to use a deprecated method providing the outdated information I do harm to them. Never harm the customer.

      Like

      • Hubertus Bigend February 10, 2014 at 3:37 pm

        You asked for the flamewar ;-)
        1. In my example, which is a real-world example, there is no old version of the library in the project. Having to search elsewhere makes the job more time-consuming and thereby more costly.
        2. Having to analyze the code that uses the method in order to determine what it does is, even in a best-case scenario, more time-consuming and thereby more costly.
        3. I, being a developer and, as such, customer when it comes to libraries, do not need nor want library developers to discourage me of something by inconveniencing me, which is decidedly paternalizing, too. To mark a method as deprecated by annotation and/or JavaDoc is absolutely sufficient to make the point. And as a matter of fact, I have never been harmed by existing documentation for deprecated methods, and I’ve encountered some in my life. I have, though, been more than once inconvenienced, i.e. harmed, by absent documentation for a deprecated method in a library I had to use the latest version of, while, at the same time, refactoring the code to get rid of the deprecated method was not an option…

        Like

      • Peter Verhas February 11, 2014 at 10:07 am

        >You asked for the flamewar

        I know ;-)

        Like

  2. Peter Verhas February 10, 2014 at 3:58 pm

    1. If there is no old version of the library, then you should not use any deprecated method when you start to use the current version. If there “was” an old version of the library but currently it does not exist any more then your release management is not professional. “Having to search elsewhere” in this case means to search exactly at the place where the documentation should be.

    2. You need not analyze the code. Just read it. No documentation can be more precise than that. You want to understand what the code does in order to maintain that. How would you achieve that without understanding the code itself?

    3. You want it or not this is actually what happens when you use libraries and programming languages. You can access private variables via reflection, but this is made inconvenient. You can fluent methods but only in a specific order. You can convert in Java a `long` to `Double` but only through `double`. They are all inconvenienced.

    To get rid of a deprecated method is always an option. It is a matter of cost. If the library is not usable without the deprecated method, then the library is not well designed. Consider getting rid of the library.

    Like

  3. Pingback: Unit test deprecated methods | Java Deep

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 909 other followers

%d bloggers like this: