Встроенные аннотации

Аннотации, которые уже понимает Java

Для распространённых задач не нужно создавать собственные аннотации. В Java уже есть набор стандартных типов, которые помогают проверять намерения разработчика, документировать устаревший API и управлять диагностикой компилятора.

@Override — проверка переопределения

@Override стоит использовать каждый раз, когда метод переопределяет метод суперкласса или реализует метод интерфейса. Это превращает намерение разработчика в проверяемое условие.

class User {

    @Override
    public String toString() {
        return "User";
    }
}

Если позже имя или параметры метода случайно изменятся, компилятор не позволит молча получить новый, не связанный с переопределением метод.

@Deprecated — API лучше больше не использовать

@Deprecated помечает API, использование которого не рекомендуется. У аннотации есть элементы since и forRemoval: первый помогает указать версию появления статуса, второй — сообщить, планируется ли удаление API.

@Deprecated(since = "2.0", forRemoval = true)
void oldMethod() {
}

Обычно такую аннотацию сопровождают Javadoc-комментарием с объяснением причины и рекомендуемой заменой.

@SuppressWarnings — точечное подавление предупреждений

@SuppressWarnings говорит компилятору не показывать выбранные предупреждения для конкретного элемента. Её полезно ставить как можно ближе к месту, где предупреждение действительно осознанно принимается, а не отключать диагностику для большого класса без необходимости.

@SuppressWarnings("unchecked")
void convert(Object value) {
    var list = (java.util.List<String>) value;
}

Другие часто встречающиеся стандартные аннотации

• @FunctionalInterface фиксирует намерение иметь ровно один абстрактный метод, подходящий для lambda-выражений.
• @SafeVarargs используется в допустимых местах, когда разработчик гарантирует безопасность работы с generic varargs.