Недавно я проходил собеседование и одним из вопросов, стал такой загадочный экземпляр:
"А какое главное преимущество системы типов Kotlin перед Java"?
Честно говоря, выделить какое преимущество считалось главным, оказалось неразрешимой для меня задачей: Nothing, отсутсвие Wildcard и First-Class Functions вместо Java-костыля с Functional Interface (имеется ввиду 8я версия Java) не заняли первых мест в личном топе интервьюера, который мне предложили угадать.
Оказалось что главное в Kotlin - возможность обьявить Nullable Type и Null Safety подход (Замечу, что по моему опыту собственные или библиотечные Optional или Maybe решают эту проблему, и пишутся за 10 минут на Java 7. А еще есть аннотации Nullable, позволяющие проверять поля в сompile-time. Короче, есть много способов заставить делать Null проверки в plain Java. Ну да ладно).
Но речь пойдет не о странных вопросах, связанных со вкусовыми предпочтениями интервьюеров относительно синтаксического сахара.
Дело в том, что Null Safety в Kotlin можно сломать, притом не выходя из под его безопасного купола в суровый дикий мир Java и Null-Referrences.
Как?
Long story short: ClassLoader ведет себя интересным образом при попытке загрузить статические поля классов рекурсивно ссылающиеся на классы друг-друга.
Под катом примеры кода и подробное объяснение того, как он обманывает проверки на Nullable. Я искренне надеюсь что специфические знания Java/Kotlin для статьи не нужны - я объясню все детали на ходу, и уложу расследование в 10 минут.
Начнем.
Не буду тянуть кота за хвост. Вот код:
class ClassToLoad1() {
val classToLoad2 = ClassToLoad1.classToLoad2
//Creating single instance of object
companion object {
val classToLoad2 = ClassToLoad2()
}
}
class ClassToLoad2() {
val classToLoad1 = ClassToLoad2.classToLoad1
companion object {
val classToLoad1 = ClassToLoad1()
}
}
fun main() {
val check = ClassToLoad1()
val classToLoadRecurciveRef = check.classToLoad2.classToLoad1.classToLoad2
println(classToLoadRecurciveRef) //null
classToLoadRecurciveRef.classToLoad1 //Throws NPE
}
Ни одной строчки кода на Java, ни одного предупреждения и NPE в результате выполнения.
Почему так?
Роковое стечение нескольких обстоятельств:
Рекурсивная ссылка, статическая инициализация, и не самый явный контракт поведения ClassLoader в JVM в таких случаяx.
//Рекурсивные ссылки
Давайте отсечем от нашего примера все, кроме рекурсивной ссылки классов на самих себя.
Базовый пример - это один класс, который хочет получить себя же в качестве экземпляра.
Зачем вообще так делать?
Самый распространенный кейс, где вы такую структуру встречали - это Linked List (который, кстати, тоже любят на собеседованиях).
Любая другая ссылочная структура данных, например Node в Tree, тоже будет ссылаться на себя саму. И если вы очень любите писать графы, вы возможно столкнетесь с таким кодом напрямую.
class SelfClassLoad(val s: SelfClassLoad) // warning: Constructor has non-null self reference parameter
Ого, у нас есть предупреждение!
И оно есть по вполне понятной причине - вы не сможете использовать этот класс:
class SelfClassLoad(val s: SelfClassLoad) // warning: Constructor has non-null self reference parameter
fun main() {
SelfClassLoad(
SelfClassLoad(
SelfClassLoad(
SelfClassLoad(
SelfClassLoad(
//No value passed for parameter 's'
)
)
)
)
)
}
Интересно будет так-же немного изменить пример:
class SelfClassLoad(){
val s = SelfClassLoad()
}
fun main() {
SelfClassLoad() //Stackoverflow error
}
По понятным причинам, мы просто получим StackOverflow - бесконечная инициализация себя к добру не приводит.
Но будет ли у нас предупреждение, если мы попробуем создать рекурсивную связку из двух классов?
class SelfClassLoad1(val s2: SelfClassLoad2)
class SelfClassLoad2(val s1: SelfClassLoad1) //No warnings
Такой кейс warning уже не выдает.
Issue на эту тему уже создан:
И это первая ступенька на пути к нашему NPE.
//Статическая инициализация
Что происходит в Kotlin когда вы создаете Companion Object?
Если вы пытались вызвать подобный код из Java - то вы знаете о том, что в вашем классе будет находиться статическая ссылка на объект-компаньон.
Если попробовать транслировать Kotlin в Java, получится что-то подобное:
public final class ClassToLoad1 {
@NotNull
private static final ClassToLoad2 classToLoad2;
@NotNull
public static final Companion Companion; //Here, it's "static"
@NotNull
public final ClassToLoad2 getClassToLoad2() {
return this.classToLoad2$1;
}
static {
Companion = new Companion(null);
classToLoad2 = new ClassToLoad2();
}
public static final class Companion {
@NotNull
public final ClassToLoad2 getClassToLoad2() {
return classToLoad2;
}
private Companion() {
}
public Companion(DefaultConstructorMarker $constructor_marker) {
this();
}
}
}
Опытные Java разработчики уже поняли к чему все идет, (если конечно не поняли с самого начала), а для широкой аудитории оставлю пояснение:
Ключевое слово static, делает ровно то, что оно гласит - объект становится статичным. А в мире JVM это значит, что этот объект находится в специальной области памяти - Permanent Generation Space.
Это означает 2 вещи:
1. Объект в static будет жить пока жива его JVM.
2. Он будет проинициализирован (положен в PermGen) 1 раз. (Да, да есть кейсы когда это не правда, это на данный момент Out of Scope)
Для тех, кто вспомнил про синглтоны:
Возможно вы сейчас подумали что-то вроде "А зачем тогда нужен сложный синглтон с Syncronized если static'a достаточно?".
Ответ: синхронизация, и прочие техники нужны когда вам нужно инициализировать синглтон отложенно.
class Singleton1{
public final static Singleton1 singleton = new Singleton1()
} //Warranty to be single time initialized, but will init on class init.
class Singleton2{
private static Singleton2 singleton;
public static void getSingleton(){
if(singleton == null)
singleton = new Singleton2()
return singleton;
}
} //Late init but no warranty of single init in concurrent case.
Если у вас небольшой объект, который можно инициализировать сразу - то можно написать Singleton1.
Singleton2 можно написать если вы гарантируете вызов его метода get из одного потока всегда. В противном случае - он неверен, но это выходит за рамки обсуждения. Но вот неплохой пост на эту тему: https://habr.com/ru/post/27108/
Нас интересует второй нюанс. Инициализация объекта идет 1 раз, а мы тут создали 2 объекта с перекрестными ссылками друг на друга.
Как поведет себя JVM в таком случае?
//Classloader
Итак, мы пришли к нижнему уровню - загрузке класса. Когда мы первый раз пытаемся использовать класс - JVM загружает информацию о классе (в том числе статическую) в PermGen, а затем использует ее для создания экземпляров класса.
Что происходит в случае рекурсивной статической ссылки?
Примерно такая цепочка:
TryLoadClass1 -> LoadingClass1 -> FoundClass2InStatic -> TryLoadClass2 -> FoundClass1InStatic -> TryLoadClass1 -> AlreadyLoading, Null
И в результате мы получим Class1, в котором есть Class2, в котором находится ссылка на Null.
Почему оно так себя ведет, а не падает с Runtime Exception?
Мое предположение, и это только предположение - из-за обратной совместимости. Если мы исправим ClassLoader и дадим ему упасть в этом кейсе - у нас может повалиться огромное количество серверов просто из-за смены версии Java. Поэтому контракт на выдачу Null сохраняется на протяжении всех версий и останется там навсегда.
//Sidenote: Заранее думайте о контрактах, если хотите написать что-то обратно совместимое.
//Big Picture
Итак, вся цепочка событий:
Мы пишем код на Kotlin с циклической/рекурсивной ссылкой двух и и более объектов самих на себя в блоке с инициализацией. Анализатор - молчит.
Kotlin компилируется в java bytecode и переходит в чудесный мир JVM и Null.
Благодаря статической инициализации классы будут загружены 1 раз, и мы не получим StackOverflow в Runtime, как только до них дойдем.
ClassLoader попробует загрузить класс и благодаря старому, неявному контракту на возврат Null поставит null-refference в экземпляр Class2 при попытке обратно сослаться на Class1, который будет заблокирован собственной инициализацией, в контексте которой как раз и происходит инициализация Class2. Схемка:
loading Class1 -> loading Class2 -> try load Class1 - result nullБинго, мы провели анализатор и получили Null в контексте, где Kotlin его совершенно не ждет.
Наслаждаемся нашим NPE
//Критикуешь - предлагай
Ну, действительно. Критиковать все могут, а решение то какое?
Давайте для начала, посмотрим на пример решения такой проблемы в другом языке.
Я - мобильный разработчик, поэтому мне близок Swift:
//Won't compile
enum RelationDirect{//Error about recursive type declaration shown
case Blocks(RelationBT)
}
enum RelationBT{
case Reffers(RelationRevese)
}
enum RelationRevese{
case BlockedBy(RelationDirect)
}
Такой код в свифте просто не скомпилируется, вам нужно пометить его отдельным ключевым словом indirect:
//Compiles
indirect enum RelationDirect{ //No errors
case Blocks(RelationBT)
}
...
Но есть одна проблема - если мы просто возьмем решение из Swift - мы сломаем Backward Compatibility - при обновлении часть проектов перестанет собираться.
Нельзя просто взять и все сломать - это не JVM Way.
Я подумал некоторое время об этой проблеме (целых 45 минут), и возможно придумал решение.
Мы не можем сломать старый код, но можем сделать так, чтобы в старом коде возникли Warnings (подробнее о том, как может работать warning - в тикете), которые посоветуют добавить keyword, который пометит для компилятора Kotlin этот класс, как требующий проверки. Это является дополнением контракта, а не его изменением, поэтому не ломает совместимость (по крайней мере, на первый взгляд).
Примерно таким образом в Java 1.1 были добавлены final, и таким же образом работает val в Kotlin: Мы не заставляем компилятор бросать exception, если мы модифицируем любое поле. Но мы можем пометить поле, и попросить компилятор бросить exception, тогда и только тогда когда оно помечено. На мой вкус, это даже более элегантное решение, чем то, что используется в Swift.
В коде это будет выглядеть так:
Warning без keyword:
//Compiles with warning
sealed class RelationDirect(
val opposite: RelationReverseSealed
) { //Warning - add selfref key to enable checks for self-refference in initializers
object Blocks : RelationDirectSealed(RelationReverseSealed.IsBlockedBy)
}
sealed class RelationReverse(
val opposite: RelationDirectSealed
) {
object IsBlockedBy : RelationReverseSealed(RelationDirectSealed.Blocks)
}
Добавление keyword, теперь компилятор чекает иерархию и находит проблему:
//Won't compile
sealed selfref class RelationDirect(
val opposite: RelationReverseSealed
) { //Error, initializer self reffrence detected
object Blocks : RelationDirectSealed(RelationReverseSealed.IsBlockedBy)
}
sealed class RelationReverse(
val opposite: RelationDirectSealed
) {
object IsBlockedBy : RelationReverseSealed(RelationDirectSealed.Blocks)
}
Но, я не претендую на идеальные знания Kotlin и Java, JVM и компиляторов и тут будет интересен комментарий от JetBrains. Было бы здорово, если бы вы дополнили эту статью. Или помогли поправить, если я где-то ошибся в объяснении.
Напоследок, я бы хотел сказать, что это не первый кейс в моей жизни, когда меня подводило излишнее доверие языку, тулингу и библиотекам. Singleton может быть не один, если вы забыли про один нюанс связанный с ClassLoader. ConcurrentHashMap.computeIfAbsent - может оказаться местом где заблокируются все треды вашего сервера, хоть он и считается потокобезопасным (в Java 8). И это реальные production кейсы, которые мне пришлось расследовать.
Поменьше доверяйте тулингу и embedded фичам, и всегда запускайте тесты.
А если у вас есть интересные кейсы из собственного опыта, когда какая-нибудь функциональность встроенная в библиотеку/язык отказывала при специфических обстоятельствах - было бы интересно увидеть эту историю в комментариях.