Как более эффективно использовать аннотации @Nullable и @Nonnull?

Я могу видеть , что @Nullableи @Nonnullаннотации могут быть полезными в предотвращении NullPointerExceptions , но они не распространяются очень далеко.

• Эффективность этих аннотаций полностью падает после одного уровня косвенного обращения, поэтому, если вы добавляете только несколько, они не распространяются очень далеко.
• Поскольку эти аннотации плохо соблюдаются, существует опасность предположить, что значение, отмеченное значком, @Nonnullне является нулевым, и, следовательно, не выполнять нулевые проверки.

Приведенный ниже код заставляет параметр, отмеченный значком, не @Nonnullвызывать nullникаких жалоб. NullPointerExceptionПри запуске выдает ошибку.

public class Clazz {
    public static void main(String[] args){
        Clazz clazz = new Clazz();

        // this line raises a complaint with the IDE (IntelliJ 11)
        clazz.directPathToA(null);

        // this line does not
        clazz.indirectPathToA(null); 
    }

    public void indirectPathToA(Integer y){
        directPathToA(y);
    }

    public void directPathToA(@Nonnull Integer x){
        x.toString(); // do stuff to x        
    }
}

Есть ли способ сделать эти аннотации более строгими и / или распространяться дальше?

Краткий ответ: я предполагаю, что эти аннотации полезны только для вашей IDE, чтобы предупредить вас о потенциально возможных ошибках нулевого указателя.

Как сказано в книге «Чистый код», вам следует проверять параметры вашего общедоступного метода, а также избегать проверки инвариантов.

Еще один хороший совет - никогда не возвращать нулевые значения, а вместо этого использовать шаблон нулевого объекта .

Помимо того, что ваша среда IDE дает вам подсказки при переходе nullк методам, которые ожидают, что аргумент не будет нулевым, есть и другие преимущества:

• Инструменты статического анализа кода могут тестировать то же, что и ваша IDE (например, FindBugs)
• Вы можете использовать АОП, чтобы проверить эти утверждения.

Это может сделать ваш код более удобным в сопровождении (поскольку вам не нужны nullпроверки) и менее подверженным ошибкам.

Я думаю, что этот исходный вопрос косвенно указывает на общую рекомендацию о том, что проверка нулевого указателя во время выполнения по-прежнему необходима, даже если используется @NonNull. Перейдите по следующей ссылке:

Новые аннотации типов в Java 8

В указанном выше блоге рекомендуется:

Необязательные аннотации типов не заменяют валидацию во время выполнения. До появления аннотаций типов основное место для описания таких вещей, как допустимость значений NULL или диапазоны, находилось в документации javadoc. С аннотациями типа это сообщение входит в байт-код для проверки во время компиляции. Ваш код по-прежнему должен выполнять проверку во время выполнения.

При компиляции исходного примера в Eclipse в соответствии с требованиями 1.8 и с включенным нулевым анализом на основе аннотаций мы получаем следующее предупреждение:

    directPathToA(y);
                  ^
Null type safety (type annotations): The expression of type 'Integer' needs unchecked conversion to conform to '@NonNull Integer'

Это предупреждение сформулировано аналогично тем предупреждениям, которые вы получаете при смешивании обобщенного кода с устаревшим кодом с использованием необработанных типов («неконтролируемое преобразование»). У нас здесь точно такая же ситуация: у метода indirectPathToA()есть "устаревшая" подпись, так как он не определяет никакого нулевого контракта. Инструменты могут легко сообщить об этом, поэтому они будут преследовать вас по всем переулкам, где нулевые аннотации нужно распространять, но еще не сделано.

И при использовании умного @NonNullByDefault даже не нужно говорить это каждый раз.

Другими словами: «распространяются ли нулевые аннотации очень далеко», может зависеть от используемого вами инструмента и от того, насколько строго вы выполняете все предупреждения, выдаваемые этим инструментом. С нулевыми аннотациями TYPE_USE у вас, наконец, есть возможность позволить инструменту предупреждать вас обо всех возможных NPE в вашей программе, потому что пустота стала интричным свойством системы типов.

Я согласен с тем, что аннотации «далеко не распространяются». Однако я вижу ошибку со стороны программиста.

Я понимаю Nonnullаннотацию как документацию. Следующий метод выражает необходимость (в качестве предварительного условия) ненулевого аргумента x.

    public void directPathToA(@Nonnull Integer x){
        x.toString(); // do stuff to x        
    }

Следующий фрагмент кода содержит ошибку. Метод вызывает directPathToA()без принуждения, которое не yравно NULL (то есть, это не гарантирует предварительное условие вызываемого метода). Одна из возможностей - добавить Nonnullаннотацию к indirectPathToA()(распространяя предварительное условие). Вторая возможность - проверить нулевое значение yin indirectPathToA()и избежать вызова directPathToA()when yis null.

    public void indirectPathToA(Integer y){
        directPathToA(y);
    }

Если вы используете Kotlin, он поддерживает эти аннотации, допускающие значение NULL, в своем компиляторе и не позволит вам передать значение NULL в метод java, который требует аргумента, отличного от NULL. Событие, хотя этот вопрос изначально был нацелен на Java, я упоминаю эту функцию Kotlin, потому что она специально нацелена на эти аннотации Java, и вопрос звучал так: «Есть ли способ сделать эти аннотации более строгими и / или распространяться дальше?» и эта функция делает эти аннотации более строгими .

Класс Java с использованием @NotNullаннотации

public class MyJavaClazz {
    public void foo(@NotNull String myString) {
        // will result in an NPE if myString is null
        myString.hashCode();
    }
}

Класс Kotlin вызывает класс Java и передает значение null для аргумента, аннотированного с помощью @NotNull

class MyKotlinClazz {
    fun foo() {
        MyJavaClazz().foo(null)
    }
}  

Ошибка компилятора Kotlin при применении @NotNullаннотации.

Error:(5, 27) Kotlin: Null can not be a value of a non-null type String

см. http://kotlinlang.org/docs/reference/java-interop.html#nullability-annotations

Что я делаю в своих проектах, так это активирую следующий параметр в проверке кода «Постоянные условия и исключения»:
предлагаю аннотацию @Nullable для методов, которые могут возвращать значение NULL, и сообщать обнуляемые значения, переданные параметрам без аннотации

При активации все неаннотированные параметры будут обрабатываться как ненулевые, и поэтому вы также увидите предупреждение при косвенном вызове:

clazz.indirectPathToA(null); 

Для еще более сильных проверок может оказаться хорошим выбором Checker Framework (см. Этот хороший учебник .
Примечание : я еще не использовал его, и могут возникнуть проблемы с компилятором Jack: см. Этот отчет об ошибке)

В Java я бы использовал дополнительный тип Guava . Будучи актуальным типом, вы получаете гарантии компилятора относительно его использования. Его легко обойти и получить NullPointerException, но по крайней мере сигнатура метода четко сообщает, что он ожидает в качестве аргумента или что он может вернуть.

Поскольку новая функция Java 8 является необязательной, вам больше не следует использовать @Nullable или @Notnull в своем собственном коде . Возьмите пример ниже:

public void printValue(@Nullable myValue) {
    if (myValue != null) {
        System.out.print(myValue);
    } else {
        System.out.print("I dont have a value");
}

Его можно переписать с помощью:

public void printValue(Optional<String> myValue) {
    if (myValue.ifPresent) {
        System.out.print(myValue.get());
    } else {
        System.out.print("I dont have a value");
}

Использование необязательного параметра заставляет вас проверять нулевое значение . В приведенном выше коде вы можете получить доступ к значению, только вызвав getметод.

Еще одно преимущество - код становится более читабельным . С добавлением Java 9 ifPresentOrElse функцию можно было бы даже записать как:

public void printValue(Optional<String> myValue) {
    myValue.ifPresentOrElse(
        v -> System.out.print(v),
        () -> System.out.print("I dont have a value"),
    )
}