Этот корректный способ использовать javax.annotation от JSR305?

Я думаю, это зависит от того, зачем вы добавляете аннотации.

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

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

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

Вы можете видеть '@NonNull String' как строгий подкласс String. В конце концов, любая ненулевая строка определенно является 'instanceof' @Nullable String ', но любой instanceof' @Nullable String 'может не быть экземпляром' @NonNull String '(этого не было бы, если бы он было null, например).

Если посмотреть на это с этой точки зрения, @Nullable и @NonNull являются информацией о типе и поэтому вполне разумны в интерфейсах. Вы указываете разработчикам, что они могут возвращать значение NULL, и что им не нужно беспокоиться о входных значениях NULL, и вы указываете вызывающим абонентам, что они не должны передавать значение NULL и что они должны ожидать выхода NULL.

Конечно, , хотя это все очень разумно, vanilla javac v1.6 определенно не t обеспечить соблюдение любого из этих правил так, как оно обеспечивает безопасность типов для фактических типов. Но можно мечтать или использовать что-то вроде pmd или findbugs, чтобы проверить эти аннотации.

Однако аннотаций @NonNull и @Nullable недостаточно для полной системы типизации null. Я действительно не знаю, почему JSR305 не занимается этим, но есть третий тип: «@MaybeNull». Он будет отображаться внутри параметров дженериков; в любом другом месте он будет иметь то же значение, что и @Nullable.

public static void addIfNotNull (List <@MaybeNull T> list, @Nullable T item) { Я действительно не знаю, почему JSR305 не занимается этим, но есть третий тип: «@MaybeNull». Он будет отображаться внутри параметров дженериков; в любом другом месте он будет иметь то же значение, что и @Nullable.

public static void addIfNotNull (List <@MaybeNull T> list, @Nullable T item) { Я действительно не знаю, почему JSR305 не обращается к этому, но есть третий тип: «@MaybeNull». Он будет отображаться внутри параметров дженериков; в любом другом месте он имел бы то же значение, что и @Nullable.

public static void addIfNotNull (List <@MaybeNull T> list, @Nullable T item) { если (элемент! = null) list.add (элемент); }

Если в аннотации к первой букве «T» стоит «@Nullable», то вы не сможете передавать ненулевые списки, что сделало бы довольно бесполезный API. С другой стороны, если бы это был @NonNull, вы не могли бы передать список, допускающий значение NULL. На практике не имеет значения, что вы туда переместите, это (A) никогда не вызовет NullPointerException и (B) никогда нарушают аннотацию. Итак, вам нужен способ выразить: меня не волнует, является ли эта конкретная «T» Nullable или нет; Я буду проверять значение null, когда буду читать из него, и я никогда не буду писать null, так что это не имеет значения.

Разница между @MaybeNull и @Nullable аналогична разнице между '? расширяет Number 'и' Number 'в дженериках. Вне дженериков они означают одно и то же, но в дженериках есть разница.

Так что, не надо.