Android support annotation nonnull

Support Annotations — аннотации для кода

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

По умолчанию аннотации не включены, они идут как отдельная библиотека. Но она входит в состав библиотеки appcompat. Если вы не используете appcompat, то подключите библиотеку аннотаций самостоятельно.

Так как на сегодняшний день проекты по умолчанию используют appcompat, то будем считать, что аннотации всегда готовы к употреблению.

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

Аннотации для ресурсов

Для первого знакомства приведу пример с использованием ресурсов. В коде мы часто используем ресурсы строк, изображений, идентификаторов и т.п. По сути ресурс в данном случае является числом типа int. Подготовим ресурсы для имён котов в res/strings.xml

Напишем вспомогательный метод для генерации имени кота, используя строковый ресурс.

Студия не замечает ошибок, метод написан правильно и даже работает.

Но никто вам не помешает написать и такие варианты:

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

Как избежать этих ошибок, перепишем метод с добавлением аннотации:

Теперь студия будет подчёркивать неправильные параметры 451 или R.mipmap.ic_launcher и выводить предупреждение, что она ожидает строковые ресурсы, а не любые выдуманные вами числа.

Вы можете использовать аннотации @AnimatorRes, @AnimRes, @AnyRes, @ArrayRes, @AttrRes, @BoolRes, @ColorRes, @DimenRes, @DrawableRes, @FractionRes, @IdRes, @IntegerRes, @InterpolatorRes, @LayoutRes, @MenuRes, @PluralsRes, @RawRes, @StringRes, @StyleableRes, @StyleRes, @XmlRes и т.д. Если у вас есть свой тип ресурсов «foo», то можете использовать аннотацию FooRes.

@NONNULL/@NULLABLE

Поняв базовый принцип, вы теперь можете использовать и другие аннотации. Например, указать, что параметр не может быть null или, наоборот, может принимать значение null.

Студия выводит предупреждение, но позволит запустить программу. Нажатие на кнопку и опять ваш труд коту под хвост — крах приложения.

@CheckResult — ожидание результата

Метод может возвращать какое-то значение, которое нужно применить. А можно просто вызвать метод, только какой в этом смысл, если возвращаемое значение нигде не используется? Для тех, кто страдает склерозом — встречайте аннотацию @CheckResult.

Студия укажет на ошибку и откажется запускать ваше приложение. Умница.

Аннотация для продвинутых. ProGuard удаляет неиспользуемые методы при компиляции. Если она делает это ошибочно или по каким-то другим причинам вам нужно оставить метод в приложении, то используйте @Keep:

Аннотации для потоков

Существуют специальные аннотации для указания потоков.

Например, мы знаем, что методы класса AsyncTask могут работать только в определённых потоках.

Если в методе doInBackground() обратиться к какому-нибудь компоненту, то студия предупредит, что так делать нельзя.

@UiThread и @MainThread практически совпадают, но в редких случаях могут различаться. Подробности в документации.

Аннотация для цвета

Вы можете задать цвет через ресурс, используя аннотацию @ColorRes. А если перед вами стоит противоположная задача — указать значение цвета через RGB/ARGB, то используйте аннотацию @ColorInt. В этом случае при использовании цветового ресурса студия покажет ошибку.

Диапазон значений

Можно указать диапазон значений для типов float/double через аннотацию @FloatRange:

В этом случае можно использовать значения от 0.0 до 1.0. Любая попытка ввести другое значение приведёт к предупреждению.

Аналогично работает для типов int/long через аннотацию @IntRange:

Для массивов, коллекций и строк можно использовать аннотацию @Size для установки ограничений в размерах или длине строк.

• Если коллекция не должна быть пустой — @Size(min=1)
• Максимальная длина строки 15 символов — @Size(max=15)
• Массив точно состоит из двух элементов — @Size(2)
• Длина массива должна быть кратна двум (например, координаты точек X и Y) — @Size(multiple=2)

Аннотации для разрешений

Если ваш метод использует функциональность, которая доступна через разрешения, то можете указать через аннотацию @RequiresPermission:

Если имеются несколько подходящих разрешений, то можно использовать атрибут anyOf, чтобы выбрать один из них:

А если нужно выбрать несколько разрешений, то используйте атрибут allOf:

Разрешения для намерений

Если есть разрешения на чтение или запись, то можно указать нужный режим через аннотации @Read или @Write:

Суперкласс

Если метод должен использовать вызов суперкласса, то используем аннотацию @CallSuper:

Остальные аннотации

В документации вы можете узнать о других аннотациях: IntDef/StringDef, @VisibleForTesting и т.д.

Источник

Каковы правильные применения @NonNull и @Nullable?

Я запутался в правильном использовании этих аннотаций.

Информация в документации для @NonNull говорит:

Обозначает, что возвращаемое значение параметра, поля или метода никогда не может быть нулевым.

Что это означает в случае параметров, когда нет ничего, чтобы остановить передачу null ?

Например, предположим, что у меня есть класс MyObject и что экземпляр может иметь или не иметь заголовок.

Здесь я использую null для представления отсутствия заголовка, но это детализация реализации, поэтому мне не нужен ни один метод установки и очистки заголовка.

Если я @Nullable title поля как @Nullable , студия Android сообщает мне, что параметр setTitle должен быть также отмечен как @Nullable (но это противоположность тому, что я хочу).

Если я setTitle методу setTitle как @NonNull я получаю предупреждение о том, что title == null состояния title == null всегда является false .

Какое правильное использование этих аннотаций в таком случае? Если @NonNull означает, что параметр никогда не может быть null неправильно ли использовать его для обозначения не должно быть null ? Если да, есть ли правильный способ указать это?

Дело в том, что эта аннотация – это своего рода контракт, поэтому вам не нужно делать проверки, если вы правильно аннулируете свои методы. Android Studio проверяет, что вы не с этим связываетесь. Вы все равно можете игнорировать его, но это приведет к предупреждению компилятора.

Если вы опустите эту бесполезную (по контракту) проверку безопасности, она будет правильно перебрасывать nullpointer-excceptions. Но разработчик был предупрежден с вашей аннотацией.

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

Если вы отметите параметр аннотацией @Nonnull , вы сообщите каждому человеку, использующему ваш API, что они не должны передавать здесь нулевое значение, иначе они должны иметь дело с последствиями (например, NullPointerException ).

Вы можете использовать его для объявления, параметр ДОЛЖЕН быть недействительным, это, по-моему, действительный прецедент.

Идем дальше и помечаем параметр методу @NonNull как @NonNull .

Это гарантирует, что компилятор выдает ошибку, когда какой-то код вызывает setTitle со значением, которое может быть нулевым . Поэтому компилятор гарантирует, что setTitle никогда не вызывается с null . Поэтому вы можете удалить null проверку в вашем методе, в результате чего заголовок «title == null всегда остается ложным».

Т.е. ваш код будет выглядеть так:

(Примечание: я не использую Android Studio, но я думаю, что он ведет себя аналогично Eclipse. В Eclipse я получаю ошибку Null type mismatch: required ‘@NonNull String’ but the provided value is null(/inferred as @Nullable) при попытке Передать null или выражения, которые могут иметь значение null для setTitle.)

BTW: также аннотирование определения title поля с помощью @Nullable сделает его более явным title также может содержать null значения.

Если вы помечаете аргумент @NonNull, то пользователь вашего метода должен выполнить нулевую проверку, так как @NonNull не будет захватывать NPE во время выполнения. Так, например, если у вас был класс утилиты со вспомогательными методами, которые проверяют значение null перед выполнением, то вы должны пометить эти аргументы как @Nullable, так как вы технически можете передать нулевое значение, но безопасно проверяете его.

Источник

импорт NotNull или Nullable и Android Studio не будут компилироваться

когда я добавляю @NotNull или @ nullable аннотации к параметру Android Studio автоматически помогает мне с добавлением/lib / аннотаций.jar и импорта

но после этого проект не компилируется. Если я также удалю аннотации, но сохраню операторы импорта, проект все равно не будет компилироваться. но если я удаляю операторы импорта для NotNull и Nullable, проект компилируется штраф в размере!

Android Studio дает общий ошибка:

под управлением gradlew compileDebug из cmd дает небольшой намек:

поэтому я проверил переменные среды, и они установлены как:

у кого-нибудь есть идеи для этого? (Я новичок в программировании на java и android)

7 ответов

Я думаю, правильный способ-использовать оригинальную библиотеку JetBrains из репозитория MavenCentral в вашей сборке.зависимости gradle (последняя доступная версия в этом примере):

вы также можете использовать собственный android @NonNull & @Nullable :

добавить построить.Gradle в:

на / задание → Настройки Проекта → инспекции и поиск «nullable».

на постоянные условия и исключения и @NotNull / @Nullable проблемы, нажмите кнопку настроить Примечания и выберите аннотации Android.

вы также можете проверить предложить @ nullable аннотации. под постоянные условия и исключения, или, возможно, настроить другие параметры.

для использования анотации поддержки андроида как — @Nullable, @NonNull etc.. В ваш проект необходимо импортировать библиотеку аннотаций поддержки android. Просто добавьте эту строку в dependensies в файле gradle

и импортировать пакет в класс.
для использования @nullable аннотация:

больше информации вы можете найти здесь разработчики Android

на данный момент в API Android или в библиотеке поддержки нет аннотаций NonNull/Nullable. Вы также не можете использовать IntelliJ, так как они не находятся в пути к классам компиляции при построении с помощью Gradle.

тем не менее, вы можете легко создать свой собственный. Это очень просто:

после этого вы можете настроить IntelliJ (или Android Studio), чтобы распознать этот (и соответствующий @Nullable ) быть аннотацией по умолчанию, используемой для Нулевые проверки.

для этого перейдите в настройки IntelliJ в разделе Inpections , а затем найти @NotNull/@Nullable problems вход под Probable Bugs в дереве инспекции.

выберите пункт и в правом нижнем углу у вас будет кнопка «настроить аннотации». Это позволит вам установить свои собственные аннотации в качестве одного intelliJ будет использовать для этой проверки.

самый простой способ добавить следующее в раздел зависимостей вашей сборки.файл gradle.

EDIT: обновлено для использования идеи @RichieHH для использования репозитория maven, что, безусловно, является способом сделать это.

в настоящее время, вы должны использовать аннотации android.поддержка.аннотация. Я просто не уверен, когда они добавили их в docs нет типичного предложения «добавлено на уровне API X», и мне не хочется читать блоги и т. д. >]

лучший способ-использовать зависимость maven

Источник

Какую аннотацию @NotNull Java следует использовать?

Я пытаюсь сделать мой код более читабельным, а также использовать такие инструменты, как проверка кода IDE и / или статический анализ кода (FindBugs и Sonar), чтобы избежать исключений NullPointerException. Многие инструменты кажутся несовместимыми с @NotNull / @NonNull / @Nonnull аннотациями друг друга, и перечисление их всех в моем коде было бы ужасно читать. Какие-нибудь предложения, какой из них является «лучшим»? Вот список эквивалентных аннотаций, которые я нашел:

javax.validation.constraints.NotNull
Создан для проверки во время выполнения, а не для статического анализа.
документация

edu.umd.cs.findbugs.annotations.NonNull
Используется FindBugs статического анализа и , следовательно , эхолота (теперь Sonarqube )
документации

javax.annotation.Nonnull
Это может работать и с Findbugs, но JSR-305 неактивен. (См. Также: Каков статус JSR 305? ) Источник

org.jetbrains.annotations.NotNull
Используется IntelliJ IDEA IDE для статического анализа.
документация

lombok.NonNull
Используется для управления генерацией кода в Project Lombok .
Заполнение аннотации, так как нет стандарта.
источник , документация

android.support.annotation.NonNull
Аннотация для маркеров, доступная в Android, предоставляется документацией пакета support-annotations

org.eclipse.jdt.annotation.NonNull
Используется Eclipse , для анализа статического кода
документации

Начиная с JSR 305 (целью которого было стандартизировать @NonNull и @Nullable ) была неактивной в течение нескольких лет, я боюсь, что нет хорошего ответа. Все, что мы можем сделать, это найти прагматическое решение, и мое следующее:

Синтаксис

С чисто стилистической точки зрения я хотел бы избегать любых ссылок на IDE, фреймворк или любой инструментарий, кроме самой Java.

• android.support.annotation
• edu.umd.cs.findbugs.annotations
• org.eclipse.jdt.annotation
• org.jetbrains.annotations
• org.checkerframework.checker.nullness.qual
• lombok.NonNull

Что оставляет нас с javax.validation.constraints или javax.annotation . Бывший поставляется с JEE. Если это лучше, чем javax.annotation , что может в конечном итоге прийти с JSE или вообще никогда, это вопрос дискуссии. Я лично предпочитаю javax.annotation потому что я не хотел бы зависимость JEE.

Это оставляет нас с

javax.annotation

который также самый короткий.

Существует только один синтаксис, который был бы даже лучше: java.annotation.Nullable . Как закончили другие пакеты от javax до java в прошлом, javax.annotation было бы шагом в правильном направлении.

Реализация

Я надеялся, что у них у всех одинаковая тривиальная реализация, но подробный анализ показал, что это не так.

Сначала за сходство:

Все @NonNull аннотации имеют строку

• org.jetbrains.annotations который называет это @NotNull и имеет тривиальную реализацию
• javax.annotation который имеет более длительную реализацию
• javax.validation.constraints который также называет это @NotNull и имеет реализацию

Все @Nullable аннотации имеют строку

кроме (опять же) org.jetbrains.annotations с их тривиальной реализацией.

Поразительным является то, что

• javax.annotation
• javax.validation.constraints
• org.checkerframework.checker.nullness.qual

у всех есть аннотации времени выполнения ( @Retention(RUNTIME) ), в то время как

• android.support.annotation
• edu.umd.cs.findbugs.annotations
• org.eclipse.jdt.annotation
• org.jetbrains.annotations

только время компиляции ( @Retention(CLASS) ).

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

Другое важное отличие состоит в том, где в коде могут использоваться аннотации. Есть два разных подхода. Некоторые пакеты используют контексты стиля JLS 9.6.4.1. Следующая таблица дает обзор:

org.eclipse.jdt.annotation , javax.annotation И org.checkerframework.checker.nullness.qual использовать контексты , определенные в JLS 4.11, что на мой взгляд, правильный способ сделать это.

Это оставляет нас с

• javax.annotation
• org.checkerframework.checker.nullness.qual

Чтобы помочь вам сравнить дальнейшие детали, я перечислю код каждой аннотации ниже. Чтобы упростить сравнение, я удалил комментарии, импорт и @Documented аннотацию. (все они были @Documented за исключением классов из пакета Android). Я изменил порядок строк и @Target полей и нормализовал квалификации.

Для полноты, вот @Nullable реализации:

Следующие два пакета не имеют @Nullable , поэтому я перечислю их отдельно; Ломбок довольно скучный @NonNull . В на самом деле и имеет длинноватые реализацию. javax.validation.constraints @NonNull @NotNull

Служба поддержки

Из моего опыта, javax.annotation по крайней мере, поддерживается Eclipse и Checker Framework из коробки.

Резюме

Моей идеальной аннотацией был бы java.annotation синтаксис с реализацией Checker Framework.

Если вы не собираетесь использовать Checker Framework, то javax.annotation ( JSR-305 ) пока что остается лучшим выбором.

Если вы готовы покупать в Checker Framework, просто используйте их org.checkerframework.checker.nullness.qual .

источники

• android.support.annotation от android-5.1.1_r1.jar
• edu.umd.cs.findbugs.annotations от findbugs-annotations-1.0.0.jar
• org.eclipse.jdt.annotation от org.eclipse.jdt.annotation_2.1.0.v20160418-1457.jar
• org.jetbrains.annotations от jetbrains-annotations-13.0.jar
• javax.annotation от gwt-dev-2.5.1-sources.jar
• org.checkerframework.checker.nullness.qual от checker-framework-2.1.9.zip
• lombok от lombok коммита f6da35e4c4f3305ecd1b415e2ab1b9ef8a9120b4
• javax.validation.constraints от validation-api-1.0.0.GA-sources.jar

Мне очень нравится Checker Framework , представляющий собой реализацию аннотаций типов ( JSR-308 ), которая используется для реализации средств проверки дефектов, таких как средство проверки на нулевое значение. На самом деле я не пробовал других предлагать какое-либо сравнение, но я доволен этой реализацией.

Я не связан с группой, которая предлагает программное обеспечение, но я фанат.

Четыре вещи, которые мне нравятся в этой системе:

У него есть дефекты для проверки на нулевое значение (@Nullable), но также есть и для неизменяемости и интернирования (и других). Я использую первое (нулевое значение) и пытаюсь использовать второе (неизменность / IGJ). Я пробую третий, но пока не уверен, что буду использовать его в долгосрочной перспективе. Я еще не убежден в общей полезности других средств проверки, но приятно знать, что сама структура представляет собой систему для реализации множества дополнительных аннотаций и средств проверки.

Настройка по умолчанию для проверки на нулевое значение работает хорошо: ненулевое значение, кроме локальных (NNEL). В основном это означает, что по умолчанию средство проверки обрабатывает все (переменные экземпляра, параметры метода, универсальные типы и т. Д.), За исключением локальных переменных, как если бы они имели тип @NonNull по умолчанию. Согласно документации:

Значение NNEL по умолчанию приводит к наименьшему количеству явных аннотаций в вашем коде.

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

Этот каркас позволяет вам использовать его без создания зависимости от каркаса , заключив свои комментарии в комментарий: например /*@Nullable*/ . Это хорошо, потому что вы можете аннотировать и проверять библиотеку или общий код, но при этом иметь возможность использовать эту библиотеку / общий код, закодированный в другом проекте, который не использует платформу. Это хорошая особенность. Я привык к его использованию, хотя сейчас я имею тенденцию включать Checker Framework во всех моих проектах.

Фреймворк позволяет аннотировать используемые вами API-интерфейсы , которые еще не аннотированы для нулевых значений, с помощью заглушек.

Я использую тот IntelliJ, потому что меня больше всего интересует то, что IntelliJ помечает вещи, которые могут создавать NPE. Я согласен, что расстраивает отсутствие стандартной аннотации в JDK. Говорят о его добавлении, он может превратиться в Java 7. В таком случае будет еще один на выбор!

Согласно списку возможностей Java 7 аннотации типа JSR-308 откладываются до Java 8. Аннотации JSR-305 даже не упоминаются.

Немного информации о состоянии JSR-305 в приложении к последней версии JSR-308. Это включает в себя наблюдение, что аннотации JSR-305 кажутся заброшенными. Страница JSR-305 также показывает его как «неактивный».

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

Фактически, JSR-308 не определяет какие-либо типы / классы аннотаций, и похоже, что они думают, что это выходит за рамки. (И они правы, учитывая существование JSR-305).

Однако, если JSR-308 действительно выглядит как превращение в Java 8, меня не удивит, если интерес к JSR-305 возродится. AFAIK, команда JSR-305 официально не отказалась от своей работы. Они просто молчали 2+ года.

Интересно, что Билл Пью (технический лидер JSR-305) — один из тех, кто стоит за FindBugs.

Для проектов Android вы должны использовать android.support.annotation.NonNull и android.support.annotation.Nullable . Эти и другие полезные аннотации для Android доступны в библиотеке поддержки .

Сама библиотека поддержки также была аннотирована этими аннотациями, так что, как пользователь библиотеки поддержки, Android Studio уже проверит ваш код и отметит потенциальные проблемы на основе этих аннотаций.

Если кто-то просто ищет классы IntelliJ: вы можете получить их из репозитория maven с помощью

JSR305 и FindBugs созданы одним и тем же человеком. Оба плохо обслуживаются, но являются стандартными и поддерживаются всеми основными IDE. Хорошей новостью является то, что они работают хорошо, как есть.

2. Добавьте аннотацию к каждому пакету: package-info.java

ОБНОВЛЕНИЕ : По состоянию на 12 декабря 2012 года JSR 305 числится как «неактивный». Согласно документации:

JSR, который был признан Исполнительным комитетом «спящим», или тот, который достиг конца своей естественной жизни.

Похоже , JSR 308 является превращение его в JDK 8 , и хотя JSR не определяет @NotNull, сопровождающий Checkers Framework делает. На момент написания этой статьи плагин Maven не работал из-за этой ошибки: https://github.com/typetools/checker-framework/issues/183

Различают статический анализ и анализ времени выполнения. Используйте статический анализ для внутренних вещей и анализ времени выполнения для открытых границ вашего кода.

Для вещей, которые не должны быть нулевыми:

Проверка во время выполнения: используйте «if (x == null) . » (нулевая зависимость) или @ javax.validation.NotNull (с проверкой bean-компонента) или @ lombok.NonNull (простой и простой) или guavas Preconditions.checkNotNull (.. .)

• Используйте Необязательный для типов возвращаемых методов (только). Либо Java8, либо гуава.

Статическая проверка: используйте аннотацию @NonNull

Там, где это уместно, используйте аннотации @ . NonnullByDefault на уровне класса или пакета. Создайте эти аннотации самостоятельно (примеры легко найти).

• Иначе, используйте @ . CheckForNull при возврате метода, чтобы избежать NPE

Это должно дать наилучший результат: предупреждения в среде IDE, ошибки от Findbugs и checkerframework, значимые исключения во время выполнения.

Не ожидайте, что статические проверки станут зрелыми, их имена не стандартизированы, а разные библиотеки и IDE обрабатывают их по-разному, игнорируют их. Классы JSR305 javax.annotations. * Выглядят как стандартные, но это не так, и они вызывают разделение пакетов с Java9 +.

Некоторые примечания к объяснениям:

• Аннотации Findbugs / spotbugs / jsr305 с пакетом javax.validation. * Конфликтуют с другими модулями в Java9 +, также могут нарушать лицензию Oracle
• Аннотации Spotbugs по-прежнему зависят от аннотаций jsr305 / findbugs во время компиляции (во время написания https://github.com/spotbugs/spotbugs/issues/421 )
• jetbrains @NotNull имя конфликтует с @ javax.validation.NotNull.
• аннотации jetbrains, eclipse или checkersframework для статической проверки имеют преимущество перед javax.annotations в том, что они не конфликтуют с другими модулями в Java9 и выше
• @ javax.annotations.Nullable не означает для Findbugs / Spotbugs то, что вы (или ваша IDE) думаете, что это значит. Findbugs проигнорируют это (на участниках). Грустно, но верно ( https://sourceforge.net/p/findbugs/bugs/1181 )
• Для статической проверки вне IDE существует 2 бесплатных инструмента: Spotbugs (ранее Findbugs) и checkersframework.
• Библиотека Eclipse имеет @NonNullByDefault, jsr305 имеет только @ParametersAreNonnullByDefault. Это просто удобные обертки, применяющие базовые аннотации ко всему в пакете (или классе), вы можете легко создавать свои собственные. Это может быть использовано на упаковке. Это может конфликтовать с сгенерированным кодом (например, lombok).
• Следует избегать использования lombok в качестве экспортированной зависимости для библиотек, которыми вы делитесь с другими людьми: чем меньше транзитивных зависимостей, тем лучше
• Использование инфраструктуры проверки Bean является мощным, но требует больших накладных расходов, так что это излишне, просто чтобы избежать ручной проверки нуля.
• Использование Optional для полей и параметров метода является спорным (об этом легко найти статьи)
• Нулевые аннотации Android являются частью библиотеки поддержки Android, они поставляются с множеством других классов и не очень хорошо работают с другими аннотациями / инструментами.

До Java9 это моя рекомендация:

Обратите внимание, что нет способа заставить Spotbugs выдавать предупреждение при разыменовании параметра метода, допускающего значение NULL (на момент написания, версия 3.1 Spotbugs). Может быть, проверочная схема может сделать это.

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

Для случаев, когда подход с разделенным интерфейсом не практичен, следующий подход является компромиссом:

Это помогает клиентам не передавать ноль (писать правильный код), возвращая при этом полезные ошибки, если они это делают.

Источник