Во что Sealed Class конвертируется в JVM

Ключевая особенность и механизм преобразования

В первую очередь, важно понимать, что Sealed Class (или Sealed Interface) в Kotlin — это средство управления иерархией наследования на уровне компилятора Kotlin. Это абстракция, которая контролируется исходным кодом. Ключевая мысль: на уровне JVM байт-кода не существует специального, нативного понятия "запечатанного класса". Вся "магия" реализуется силами компилятора Kotlin (kotlinc), который генерирует обычные классы Java, а затем применяет дополнительные проверки и аннотации.

Преобразование в JVM байт-код: два ключевых механизма

Исходный код на Kotlin:

sealed class Result {
    data class Success(val data: String) : Result()
    data class Error(val message: String) : Result()
}

1. Основное преобразование: Обычные классы

Каждый запечатанный класс и все его прямые наследники компилируются в самые обычные Java-классы. С точки зрения JVM, это просто абстрактный (или не абстрактный) родительский класс и набор его подклассов.

• Result становится абстрактным классом (если он объявлен как sealed class).
• Result.Success и Result.Error становятся final классами (поскольку data class по умолчанию final в Kotlin).

Важное уточнение: Если запечатанный класс объявлен как sealed interface, он будет скомпилирован в обычный Java-интерфейс, а его реализации — в классы, реализующие этот интерфейс.

2. Ключевой механизм контроля: Аннотация @Metadata и permits

Для реализации ограничений sealed-иерархии компилятор Kotlin использует два взаимодополняющих подхода:

a) Аннотация @kotlin.Metadata

В скомпилированный байт-код каждого sealed-класса добавляется специальная аннотация @Metadata. Внутри неё хранится список бинарных имён (binary names) всех разрешённых подклассов. Это внутренний формат компилятора Kotlin, который используется им при анализе кода для выполнения статических проверок (например, при компиляции when-выражений, которые должны быть exhaustive). JVM сама по себе эту аннотацию не интерпретирует.

b) Атрибут permits (в современных версиях Kotlin/JVM)

Начиная с Kotlin 1.5 и при использовании целевой версии JVM 15+, компилятор может (опционально) использовать новую возможность языка Java — модификатор sealed и предложение permits. В этом случае Kotlin генерирует байт-код, который выглядит для JVM как нативный sealed-класс Java. Это делает иерархию "понятной" и для инструментов, работающих непосредственно с байт-кодом (например, новых версий javac).

Пример того, как это может выглядеть в псевдокоде Java:

// Примерная структура, которую может сгенерировать компилятор
public abstract sealed class Result permits Result.Success, Result.Error {
    // ... тело класса
}
public final class Result.Success extends Result { /* ... */ }
public final class Result.Error extends Result { /* ... */ }

Важно: Это не меняет семантики для Kotlin-кода, но улучшает взаимодействие с Java-кодом и инструментарием JVM. При этом Kotlin-компилятор всё равно дублирует информацию в своей @Metadata аннотации для собственных нужд.

Итог и практические следствия преобразования

1. Статические проверки (exhaustiveness): Полнота проверок в when — это функция компилятора Kotlin на этапе компиляции. Компилятор анализирует список наследников из @Metadata или атрибута permits и гарантирует, что все случаи учтены. В байт-коде нет инструкций invokedynamic или специальных вызовов для этой проверки — она выполняется статически. Неполный when просто не скомпилируется.
2. Рефлексия и инстанциирование: Поскольку наследники — это обычные классы, технически можно создать их экземпляр через Java Reflection или обходные пути (например, десериализацию). Механизм sealed не является защитой времени выполнения (runtime), это ограничение времени компиляции. Однако, объявление классов-наследников в одном файле с родителем или в одном модуле (в зависимости от модификаторов доступа) сильно ограничивает возможности для обхода этих правил из корректного Kotlin-кода.
3. Взаимодействие с Java: Если sealed-иерархия скомпилирована с атрибутом permits, Java-код, начиная с версии 17, будет "видеть" её как нативную sealed-иерархию и сможет использовать в switch с pattern matching (в будущих версиях). Без permits Java-код сможет наследоваться от такого класса, если не указаны другие модификаторы доступа, что нарушит логику Kotlin-кода. Поэтому для библиотек, используемых из Java, важно продумывать модификаторы видимости.

Таким образом, Sealed Class в Kotlin конвертируется в стандартные JVM-классы, но со специальными аннотациями (@Metadata) и, опционально, с использованием JVM-атрибута permits, которые позволяют компилятору Kotlin (а в случае с permits — и Java-компилятору) выполнять статические проверки на корректность наследования и exhaustiveness в when-выражениях.