Всем привет!

Небольшое замечание. О важности проблемы null safety в Java говорит вот этот список различных видов @Null\@NotNull аннотаций Java, которые поддерживает Kotlin при проверке типов: https://kotlinlang.org/docs/java-interop.html#nullability-annotations К слову, все они не входят в стандартную библиотеку Java.

#java #kotlin #nullsafety

Всем привет в 2023 году!

Уже писал про плюсы Kotlin, забыл про еще один - язык подталкивает к правильному написанию кода по умолчанию. Что имеется в виду:

1) все типы по умолчанию not null, для nullable типа нужно добавить ? к названию типа. String и String? Что дает: уменьшает число переменных с null в программе, следовательно, уменьшает число NPE
2) все коллекции по умолчанию immutable, чтобы создать изменяемую коллекцию надо использовать метод с mutable в названии: listOf(1,2) и mutableListOf(1,2). Что дает: упрощает оптимизацию байт-кода компилятором или JVM.
3) все классы и методы по умолчанию final, чтобы сделать открытый для расширения метод или класс - нужно указать ключевое слово open. Это приводит к тому, что открытыми будут только те классы и методы, которым это точно нужно)

Сюда же я бы добавил паттерны, реализованные в языке Kotlin. По сути это и синтаксический сахар, и эталонные реализации по умолчанию, уменьшающие вероятность ошибок при самостоятельной реализации:
4) синглтон - объявление класса-синглтона с помощью ключевого слова object
5) делегат - делегирование функционала класса или отдельного property через ключевое слово by

Почему важно по умолчанию показывать, как писать код правильно?
Приведу два примера:
1) Когда давным давном в далекой галктике Borland была среды быстрой разработки (RAD) Delphi. Хорошая была IDE, сделала одну большую ошибку - сильно завязалась на Windows и проиграла конкуренцию Visual Studio при массовом переходе на .NET.
Но был еще один серьезный недостаток. При создании нового проекта по умолчанию создавалось 3 файла: файл проекта, файл формы с UI компонентами и файл для обработчиков событий на форме. БольшАя часть разработчиков в файле для обработчиков хранила и бизнес-логику - Model + Controller. Лично я первое время делал именно так((( А всего-то надо было сделать еще один файл, назвать его скажем Logic.pas.
2) Еще похожий случай более близкий к нам по времени. Есть такой язык PHP. Язык простой в обучении, без компиляции, с нестрогой типизацией, с мощными и простыми средствами для обработки HTTP запросов, генерации HTML и работой с БД. Такая простота приводит к тому, что опять же многие PHP разработчики не думают о разделении кода по классам. Получаются огромные php скрипты, где смешаны M, V и C.

#kotlin #languages #nullsafety

Всем привет!

В последние годы стала "модной" тема null safety. Суть в том, что не нужно хранить и передавать null значения, чтобы не напороться на Null Pointer Exception. В том же Kotlin null safety встроена в язык - все типы по умолчанию не могут содержать null.
И на самом деле это правильный подход. Но есть нюансы)

Рассмотрим такой случай - мы идем куда-то за данными, данные по бизнес-процессу там обязаны быть. Например, мы прихранили id записи где-то в пользовательском контексте в начале процесса и идем за данными в конце процесса. Но данных нет. Следуя null safety можно просто создать пустой объект - например, с помощью конструктора. Как вариант, часть полей этого объекта будет проинициализирована значениями по умолчанию.

Так вот - в случае, когда данных нет из-за какой-то нештатной редко воспроизводимой ситуации: неверные тестовые данные, на сервис идет атака с перебором всех возможных значений, в процессе операции данные некорректно мигрировали, кривая архитектура - лучше просто "упасть", т.е. выбросить исключение. Есть такой принцип - fail fast. Т.к. создавая пустой объект, мы во-первых надеемся что он будет корректно обработан выше, а это может быть не так. А во-вторых - а зачем передавать управление дальше?

P.S. Как всегда - напомню каждую ситуацию нужно рассматривать индивидуально, чтобы различать отсутствие данных как часть бизнес-процесса и нештатную ситуацию.

#kotlin #code #patterns #principles #nullsafety #fail_fast

Всем привет!

Сегодня пост о крутой фиче Kotlin, которая решила одну важную проблему. И добавила другую)
Я о Null safety.
Суть ее в том, что в Kotlin любой тип представлен в двух ипостасях - одна может содержать null значения, другая - нет.
String - не может содержать null,
String? - может.
Это два разных типа, неявное приведение второго к первому "без приседаний" невозможно.
Что дает Null safety?
По умолчанию предлагается использовать тип not null, и если так и делать, то кажется, что про NPE - NullPointerException - можно забыть. А заодно забыть о проверках на null как в коде, так и в тестах. Небольшой оффтоп - проверка not null значений на null в тестах - еще один антипаттерн. Говорит о том, что пишущий этот код еще не до конца познал Kotlin)
Вроде бы все хорошо. Но есть нюанс. Что будет, если присвоить not null переменной nullable значение? Ошибка компиляции. А всегда ли компилятор знает, что это nullable значение? Если тип Kotlin - то всегда. Если тип Java - то в общем случае не знает. Что же он делает в таком случае? А ничего, просто разрешает присваивание.

//Java
public class JavaNullability {
private Boolean value;

public Boolean getValue() {
return value;
}
}

// Kotlin
class KotlinNullability {
constructor(test: JavaNullability) {
val nullValue: Boolean? = test.value
val notNullValue: Boolean = test.value
// компилятор разрешает оба варианта
}
}

Что же будет в runtime? Привычный нам в Java NPE на втором присваивании. Да, null safety не защищает от NPE в Kotlin коде.

Что тут можно сделать?

1) при взаимодействии Kotlin-Java знать nullability Java параметров, с которым мы работаем. Это может быть описание контракта - OpenAPI спецификация или любой другой контракт.
2) явная проверка на null в коде присваивания
3) самый плохой вариант, антипаттерн - всегда присваивать значения из Java nullable типам в Kotlin. Почему это плохо? nullable типы расползаются по всей программе, и в итоге мы теряем все преимущества Kotlin null safety.

P.S. Но в целом: null safety - это круто! Подробнее можно о ней можно почитать в официальной документации: https://kotlinlang.org/docs/null-safety.html#nullable-receiver

#kotlin #java #antipatterns #nullsafety

Всем привет!

Чтобы проиллюстрировать предыдущий пост - предлагаю сравнить по критерию null safety три языка: Groovy, Java и Kotlin.
Тестовая задача такая - передать null Boolean значение в конструктор и проверить его в if.

Groovy

import groovy.transform.TupleConstructor

@TupleConstructor
class GroovyNullability {
Boolean value

void checkValue() {
if (!value) {
println 'groovy value is false'
}
}
}

Т.к. в Groovy все, что не true считается false - вызов checkValue распечатает строку.

Java

public class JavaNullability {
private Boolean value;

public JavaNullability(Boolean value) {
this.value = value;
}

public void checkValue() {
if (!value) {
System.out.println("java value is false");
}
}
}


Вызов checkValue упадет c NPE: "Cannot invoke "java.lang.Boolean.booleanValue()" because "this.value" is null" на преобразовании Boolean к boolean использования в логическом выражении (boolean expression).

Kotlin

class KotlinNullability {
var value: Boolean = false

constructor(test: Boolean?) {
value = test!!
}

fun checkValue() {
if (!value) {
println("kotlin value is false")
}
}
}

Чтобы присвоить null значение not null переменной придется пойти на хитрость - через !! указать, что мы уверены, что в nullable переменной не будет null значений. И если же null все же придет - тоже будет java.lang.NullPointerException, причем без подробностей. Но на шаг раньше, еще на присваивании not null переменной.
К слову - если передать Java объект с null значением, через класс-обвертку:

constructor(test: JavaNullability) {
value = test.value
}

NPE будет чуть более подробным: "java.lang.NullPointerException: test.value must not be null"

#kotlin #java #groovy #nullsafety

Резюмирую предыдущий пост:

1) в Groovy нет null safety
2) в Java проблемы с null проявятся при попытке работы с null объектом, в т.ч. при неявных преобразованиях
3) в Kotlin с использованием Java библиотек проблемы будут проявляться при присваивании в Kotlin коде
4) чистый Kotlin = null safety

#groovy #kotlin #java #nullsafety