The Trouble with Deprecation

Java has this feature, that allows you to deprecate stuff. The compiler will then issue warnings, if those elements are used by non deprecated elements.

While this seems to be a good idea in fact it isn’t. If you have to change something, just do it and get immediately rid of all the crap or it will stay around.

Just suppose you want to change the return type of a method. You have to deprecate the old method and introduce a new method with a new (and probably awkward) name. Then you can remove the old one at some point. Another step of deprecation will allow you to rename the new method to the original name. This is not going to lead to nice code!

This entry was posted in Software Development. Bookmark the permalink.

4 Responses to The Trouble with Deprecation

  1. wirzi says:

    Deprecation might by useful if you change a widely used API
    and want to decouple dependency migration steps in the many
    different products using this API.
    Important: Remove the deprecated methods in the follow-up API
    version — after the grace period code shall be broken.

    But:
    Deprecating methods (in a local context) is in widespread use by those
    guys who are afraid of changes.
    I found them very often being afraid of their own code and “design”. (“Well,
    let’s do it quick here, we’ll fix it afterwards”).
    Aware that they do not know what happens if they change something.
    Suddenly realizing that the needed design improvements have been deferred
    every once in a while.
    If one finds himself in a situation that desperate I’d suggest:
    DEPRECATE your own idea of how software development is done
    and IMPROVE the design of your own working style at first.

    *angry*

  2. felix says:

    Really vicious thing I just had to read was an @Deprecated on private field. The trouble with the industry is really, that thinking is not very common.

  3. I personally find @deprecated _very_ useful when working with a legacy code base (eg. one without any sensible test coverage). One of the key considerations in such situations is to keep all changes as small as possible. This is also one of the hardest and least common things to do – but it is critically important.

    For example, if I have a class with a terrible interface (eg. a ‘value’ object with setters, or an entity with no behaviour methods), then I want to change that interface. I can add tests around the object and I can add my new methods. But I _must not_ attempt to immediately remove the existing methods or ways of interacting with the object, because then I would have to change all the consumers of that interface – a potentially large, complex and risky change to a system with little immediate value.

    So now I have a interface with the new ‘correct’ methods, but also with a whole slew of legacy ‘cant-remove-these-yet’ methods. How do I make sure everyone else on the team knows which methods they shouldn’t be using anymore? Enter @deprecated.

  4. felix says:

    @Chris
    I am still not convinced. I think the whole refactoring should be done in one go. You mention that deprecated tells the team how something has to be changed, i.e. someone else has to do it. This implies a not so collective code ownership. There is two things I am concerned about. First if you start doing a refactoring you are into the code, so you are the best person to do all of it. Everyone else will have to go through a “mental context switch” which takes a lot of time. Second it leaves the code in an “inconsistent” state. Old and new stuff exists in parallel.

    I completely agree with you, that the tool that should tell you about trouble in your codebase is the compiler. But ideally you should break the code and force people to fix it (one of the ideas of the java people was NOT to have compiler warnings as opposed to C++, which has plenty).

    I see the point for a provider of a library, that has independant clients. But even here it might be beneficial to dump old stuff. Just consider the jdk Vector-Hashtable-Enumerable mess, that is still with us.

Leave a Reply

Your email address will not be published. Required fields are marked *