Як ефективніше використовувати примітки @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, щоб попередити вас про потенційно помилкові помилки вказівника.

Як сказано в книзі "Чистий код", ви повинні перевірити параметри свого загальнодоступного методу, а також уникати перевірки інваріантів.

Ще одна корисна порада - це ніколи не повертати нульові значення, а використовувати замість цього Null Object Pattern .

Крім вашого IDE, який дає вам підказки при переході nullдо методів, які очікують, що аргумент не буде нульовим, є й інші переваги:

• Засоби аналізу статичного коду можуть перевірити те саме, що і ваш IDE (наприклад, FindBugs)
• Ви можете використовувати AOP для перевірки цих тверджень

Це може допомогти вашому коду бути більш ретельним (оскільки вам не потрібні nullперевірки) та менш схильним до помилок.

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

Анотації нового типу Java 8

У наведеному вище блозі рекомендується:

Додаткові анотації типу не є заміною перевірки часу виконання Перед анотаціями типів, основне місце для опису таких речей, як нульовість або діапазони, було в javadoc. З анотаціями Type це повідомлення надходить у байт-код таким чином, щоб перевірити час компіляції. Ваш код все одно повинен перевіряти час виконання.

Складаючи оригінальний приклад у програмі 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 null анотаціям , нарешті, ви маєте можливість дозволити інструменту попередити вас про всі можливі NPE у вашій програмі, оскільки nullness перетворився на інтрисичну властивість системи типу.

Я погоджуюся, що примітки "не поширюються дуже далеко". Однак я бачу помилку на стороні програміста.

NonnullАнотацію я розумію як документацію. Наступний метод виражає, що вимагає (як попередня умова) ненульовий аргумент x.

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

Наступний фрагмент коду містить помилку. Метод викликає directPathToA()без примусового виконання, що yє ненульовим (тобто не гарантує попередньої умови виклику методу). Однією з можливостей є також додавання Nonnullпримітки до indirectPathToA()(розповсюдження передумови). Можливість два, щоб перевірити на недійсність yв indirectPathToA()і уникнути виклику , directPathToA()коли yодно нуль.

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

Що я роблю в своїх проектах - це активувати наступний параметр у коді перевірки коду "Постійні умови та винятки":
Запропонувати @Nullable анотацію для методів, які, можливо, можуть повернути нульові значення та повідомити про зведені значення, передані не-анотованим параметрам

Після активації всі неанотовані параметри будуть розглядатися як ненульові, і, таким чином, ви побачите попередження про свій непрямий виклик:

clazz.indirectPathToA(null); 

Для ще більш сильних перевірок Checker Framework може бути хорошим вибором (див. Цей хороший підручник .
Примітка . Я ще цього не використовував, і можуть виникнути проблеми з компілятором Jack: дивіться цей bugreport

У Java я б використовував необов'язковий тип Guava . Будучи фактичним типом, ви отримуєте гарантії компілятора щодо його використання. Її легко обійти і отримати NullPointerException, але принаймні підпис методу чітко повідомляє, що він очікує як аргумент або що він може повернути.

Якщо ви використовуєте Kotlin, він підтримує ці анотації про нівельованість у своєму компіляторі і не дасть вам передати нуль методу java, який вимагає ненульового аргументу. Подія, хоча спочатку це питання було націлене на Java, я згадую про цю функцію Котліна, оскільки вона спеціально орієнтована на ці анотації на Java, і було питання: "Чи є спосіб зробити ці анотації більш чіткими та / або поширюватися далі?" і ця особливість робить ці коментарі більш чіткими .

Клас Java з використанням @NotNullанотацій

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

Клас Котлін, який викликає клас 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

Оскільки нова функція 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"),
    )
}