| # How and When To Deprecate APIs | Deprecation Home Page

- What "Deprecated" Means
- When to Deprecate
- How to Deprecate

- Using the @Deprecated Annotation
- Using the @deprecated Javadoc Tag

## What "Deprecated" Means

You may have heard the term, "self-deprecating humor," or humor that minimizes the speaker's importance. A deprecated class or method is like that. It is no longer important. It is so unimportant, in fact, that you should no longer use it, since it has been superseded and may cease to exist in the future.

Java provides a way to express deprecation because, as a class evolves, its API (application programming interface) inevitably changes: methods are renamed for consistency, new and better methods are added, and fields change. But such changes introduce a problem. You need to keep the old API around until developers make the transition to the new one, but you don't want them to continue programming to the old API.

The ability to deprecate a class, method, or member field solves the problem. Java supports two mechanisms for deprecation: and an annotation, (supported starting with J2SE 5.0) and a Javadoc tag (supported since 1.1). Existing calls to the old API continue to work, but the annotation causes the compiler to issue a warning when it finds references to deprecated program elements. The Javadoc tag and associated comments warn users against using the deprecated item and tell them what to use instead.

## When to Deprecate

When you design an API, carefully consider whether it supersedes an old API. If it does, and you wish to encourage developers (users of the API) to migrate to the new API, then deprecate the old API. Valid reasons to deprecate an API include:

- It is insecure, buggy, or highly inefficient
- It is going away in a future release
- It encourages bad coding practices

Deprecation is a reasonable choice in all these cases because it preserves "backward compatibility" while encouraging developers to change to the new API. Also, the deprecation comments help developers decide when to move to the new API, and so should briefly mention the technical reasons for deprecation.

It is not necessary to deprecate individual member fields (properties) of a deprecated class, unless of course you want to explain a specific point about a property.

## How to Deprecate

Starting with J2SE 5.0, you deprecate a class, method, or field by using the `@Deprecated` annotation. Additionally, you can use the `@deprecated` Javadoc tag to mark the program element as deprecated in the Javadoc, and the tell developers how to avoid the deprecated API.

Using the annotation causes the Java compiler to generate warnings when the deprecated class, method, or field is used. The compiler suppresses deprecation warnings if a deprecated compilation unit uses a deprecated class, method, or field. This enables you to build legacy APIs without generating warnings.

You are strongly recommended to use the Javadoc @deprecated tag with appropriate comments explaining how to use the new API. This ensures developers will have a workable migration path from the old API to the new API. For more information, see Using the @deprecated Javadoc Tag.

NOTE: The Java Language Specification requires compilers to issue warnings when classes, methods, or fields marked with the `@Deprecated` annotation are used. Compilers are not required by the Java Language Specification to issue warnings when classes, methods, or fields marked with the `@deprecated` Javadoc tag are accessed, although the Sun compilers currently do so. However, there is no guarantee that the Sun compiler will always issue such warnings.

### Using the @Deprecated Annotation

J2SE 5.0 introduces a new language feature called annotations (also called metadata). One of the Java language's built-in annotations is the `@Deprecated` annotation. To use it, you simply precede the class, method, or member declaration with "@Deprecated."

Using the `@Deprecated` annotation to deprecate a class, method, or field ensures that all compilers will issue warnings when code uses that program element. In contrast, there is no guarantee that all compilers will always issue warnings based on the `@deprecated` Javadoc tag, though the Sun compilers currently do so. Other compilers may not issue such warnings. Thus, using the `@Deprecated` annotation to generate warnings is more portable that relying on the `@deprecated` Javadoc tag.

NOTE: Deprecation applies to classes and to individual methods or properties, not to their names. It is possible for a single method to have deprecated and non-deprecated overloadings. It is possible for a non-deprecated property to hide or override a deprecated one, which removes deprecation. As developer of an API, it is your responsibility to deprecate overrides of a deprecated method, if in fact they should be deprecated.

#### Example

The following is a simple example of using the @Deprecated annotation from `java.lang.Thread`:

    public
    class Thread implements Runnable {
    ...
    @Deprecated
        public final void stop() {
      synchronized (this) {
    ...

### Using the @deprecated Javadoc Tag

You can use the `@deprecated` tag to make Javadoc show a program element as deprecated. The `@deprecated` tag must be followed by a space or newline. In the paragraph following the `@deprecated` tag, explain why the item has been deprecated and suggest how to avoid it.

JavaDoc generates special HTML based on `@deprecated` tags: it moves the paragraph following the `@deprecated` tag to the front of the description, placing it in italics and preceding it with a warning, "Note: foo is deprecated", in bold. It also adds "Deprecated" in bold to any index entries mentioning the deprecated entity.

The tagged paragraph can be empty, but empty deprecation paragraphs are bad form, because they do not help the user fix the warnings that arise from the deprecation. Include paragraphs marked with `@link` or `@see` tags that refer to the new versions of the same functionality. It is usually not a good idea to mention a timetable for phase-out of the deprecated API; this is a business decision that is best communicated other ways.

For more information on using the `@deprecated` Javadoc tag, see Javadoc - The Java API Documentation Generator and How to Write Doc Comments for the Javadoc Tool.

#### Example

The following examples show how to use the `@deprecated` Javadoc tag. They also illustrate the `@Deprecated` annotation, to emphasize that the two should be used together.

Here is an example of the most common form of a deprecated method (for Javadoc 1.2 and later):

    /**
     * @deprecated  As of release 3.1, replaced by {@link #getPreferredSize()}
     */
    @Deprecated public Dimension preferredSize() {
    return getPreferredSize();
    }

NOTE: For Javadoc 1.1, the standard format is different; see How to Write Doc Comments for the Javadoc Tool.

If the deprecation is a simple renaming, there is no need to say something like "this method is replaced by getPreferredSize"; the `@link` tag points the user to the replacement.

If the API reorganization was more than renaming, the deprecation may be more complex. Here is an example of a method that is being retracted:

    /**
     * Delete multiple items from the list.
     *
     * @deprecated  Not for public use in the future.
     * This method is expected to be retained only as a package
     * private method.
     * {@link #remove(int)}
     * {@link #removeAll()}
     */
    @Deprecated public synchronized void delItems(int start, int end) {
    ...
    }