Распространенным подходом к внедрению Kotlin является его использование в существующих проектах либо в новых функциях, либо путем постепенного преобразования существующего кода с Java на Kotlin. В этих сценариях очень часто только что написанный код Kotlin взаимодействует с Java, что обычно означает необходимость обработки типов платформ в Kotlin.

Типы платформ по сути являются типами, возвращаемыми из взаимодействий с Java, и обозначаются в подсказках IDE с помощью !, например (String!). Поскольку все типы в Java допускают значение NULL, компилятор Kotlin не может дать никаких гарантий безопасности для типов платформы и ослабит ошибки допустимости NULL во время компиляции. То есть он не выполняет обычные проверки во время компиляции для null обработки при работе с типами платформ.

Аннотации, допускающие обнуление

Здесь могут помочь Аннотации обнуляемости. Эти аннотации добавляются в код Java, чтобы помочь компилятору Kotlin (и IDE) определить, допускает ли тип платформы значение NULL. Это дает нам несколько преимуществ при работе с кодом Java.

Убирает тип платформы при звонке

Допустим, у нас есть метод Java, который принимает String и возвращает String с такой логикой. Обратите внимание, что вход не должен быть null, но выход может быть null:

public static String doSomething(
    String bar
) {
    if (bar.isEmpty()) return "empty";
    return null;
}

Когда мы пытаемся использовать его в Kotlin, подсказки IDE сообщают нам, что и вход, и выход String!. Это не очень полезно, потому что теперь нам нужно проверить источник, чтобы увидеть, можем ли мы передать null и следует ли ожидать null.

Добавление правильной аннотации к источнику меняет это и дает гораздо больше информации при его вызове. Теперь мы знаем, что нельзя передавать значения NULL, но следует ожидать null результата.

@Nullable
public static String doSomething(
    @NotNull String bar
) { ... }

Повторно активирует проверки допустимости значений NULL во время компиляции

Без аннотаций компилятор и IDE не выполняют обычные проверки допустимости значений NULL. Таким образом, во время компиляции нам разрешено передавать null и пропускать обработку нулевого результата. Это не сработает во время выполнения с ужасным NullPointerException.

С аннотациями, как и ожидалось, вместо этого мы получаем ошибки времени компиляции. Это сэкономило бы нам много времени на отладку!

Позволяет IntelliJ выбрать правильный тип при преобразовании в Kotlin

Изящный способ конвертировать Java в Kotlin - просто скопировать и вставить Java-код в файл Kotlin. IntelliJ автоматически преобразует фрагмент кода в Kotlin. Без аннотаций он может выбрать неправильный тип после преобразования:

fun doSomething(
    bar: String
): String { ... }

После добавления аннотаций он выбрал правильный тип вывода:

fun doSomething(
    bar: String
): String? { ... }

Примечание: если бы мы скопировали приведенный выше пример кода, IntelliJ достаточно умен, чтобы выбрать String? для вывода, поскольку он может анализировать логику функции. Однако я не уверен в степени анализа, и я видел, что для более сложных функций выбирались неправильные типы, поэтому вам нужно внимательно следить за преобразованными типами. С помощью аннотаций вы гарантированно выберете правильные типы, что сэкономит нам время.

Включает предупреждения на Java и служит документацией

Не имеют отношения к Kotlin, но аннотации также помогают нам поддерживать / отлаживать код Java, активируя предупреждения IDE.

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

В процессе анализа требований допустимости значений NULL мы могли бы также понять, что поле, которое объявлено допускающим значение NULL, на самом деле не обязательно должно допускать значение NULL (или наоборот, поле, которое не объявлено допускающим значение NULL, на самом деле имеет значение NULL, что означает, что мы уловили потенциальную NPE).

Идти вперед

Если мы по какой-либо причине добавляем новый код Java, не забудьте добавить аннотации, допускающие значение NULL, будь то переменные, свойства или входные и выходные данные методов. Это напомнит нам подумать о требованиях допустимости значений NULL на этапе проектирования, даже если кодирование на Java не обеспечивает их выполнения.

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

Конечно, идеальным подходом было бы преобразование кода Java в Kotlin. Если это вариант, может помочь метод Sprout By Delegate.

Примечание: это несколько пакетов, из которых эти аннотации официально поддерживаются, я лично рекомендую пакет javax.annotation или org.jetbrains.annotations оставаться независимым от IDE или фреймворка (Kotlin разработан Jetbrains, поэтому пакет jetbrains проходит успешно).

Другие истории, которые могут вам понравиться

Привет, если вам понравился этот пост, я подумал, что вы могли бы заинтересоваться членством в Medium, чтобы получить доступ к качественному контенту от авторов Medium, не стесняйтесь использовать мою реферальную ссылку! Вам также могут понравиться эти футболки с дизайном, вдохновленным кодом.