Kotlin Null-Safety vs ClassLoader

Недавно я проходил собеседование и одним из вопросов, стал такой загадочный экземпляр:
«А какое главное преимущество системы типов 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.

//Рекурсивные ссылки

Давайте отсечем от нашего примера все, кроме рекурсивной ссылки классов на самих себя.

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

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 уже не выдает.

И это первая ступенька на пути к нашему 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)

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.

Нас интересует второй нюанс. Инициализация объекта идет 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 фичам, и всегда запускайте тесты.

А если у вас есть интересные кейсы из собственного опыта, когда какая-нибудь функциональность встроенная в библиотеку/язык отказывала при специфических обстоятельствах — было бы интересно увидеть эту историю в комментариях.