Взаимодействие с Java — бесплатный тест онлайн

Вопрос 1 из 30

Для «Checked-контракт для Java» предлагают правку: Документировать и типизировать ожидаемые ошибки на публичной границе; для Kotlin API рассмотреть Result или доменный sealed-тип. Какой компромисс нельзя пропустить?

Граница полезности решения описывается условием: Она заставляет Kotlin-компилятор требовать try/catch у каждого вызова. Цена упрощения проявится, если без неё IOException невозможно бросить из Kotlin-функции. Throws сохраняет привычный Java-протокол, но связывает клиентов с классами исключений и усложняет композицию асинхронного кода. Главный риск формулируют так: Она перехватывает IOException и возвращает пустую строку. После внедрения придётся исходить из того, что она меняет тип исключения на RuntimeException.

Вопрос 2 из 30

Какой тест особенно важен для platform type?

// Проследите фактическое выполнение без изменения кода.
// Java stub возвращает null вопреки неаннотированной сигнатуре
val api = mock<LegacyApi> { on { findName() } doReturn null }
val result = runCatching { length(api) }

Передать реальный `null` из Java-stub и проверить контролируемую ошибку на границе адаптера. Сравнить Kotlin-исходник с декомпилированным Java, не выполняя граничный случай. Замокировать `String.length`, чтобы он возвращал ноль для null. Отключить strict nullability и считать отсутствие предупреждений тестом. Проверить только успешную строку: Java-компилятор уже исключает null.

Вопрос 3 из 30

Какой принцип лежит в основе поведения «Interop-адаптер как граница»?

// На ревью требуется объяснить причину поведения.
import kotlinx.coroutines.*
class JavaClientAdapter(private val client: LegacyClient) {
    suspend fun fetch(id: String): Item = withContext(Dispatchers.IO) {
        val raw = requireNotNull(client.fetch(id)) { "LegacyClient returned null for $id" }
        raw.toDomain()
    }
}

Механика примера описывается утверждением: После withContext Java DTO автоматически становится immutable. Anti-corruption adapter преобразует nullability, ошибки, потоки и модели владения один раз на границе платформы. Такой результат объясняют тем, что адаптер гарантирует потокобезопасность LegacyClient без знания его контракта. Ключевым считают контракт: Он нужен главным образом для создания отдельного потока на каждый Java-объект. Причина результата в том, что слой устраняет необходимость тестировать null и исключения Java API.

Вопрос 4 из 30

Почему пример «Неаннотированный Java-результат» даёт именно такой результат?

// На ревью требуется объяснить причину поведения.
// Java: String findName();  // без аннотации nullability
fun length(api: LegacyApi): Int {
    val name = api.findName()
    return name.length
}

Поведение связывают с правилом: Kotlin подставит пустую строку, если Java вернёт null. Семантика фрагмента приводит к тому, что код не компилируется, потому что любой Java String автоматически становится String. Неаннотированные Java-ссылки импортируются как platform types с ослабленной null-гарантией; Kotlin позволяет выбрать nullable или non-null использование. Контракт здесь понимают так: Платформенный тип проверяется только при сборке Java-класса и затем безопасен. Объяснение опирается на утверждение: Риск ограничен reflection; обычный прямой вызов в показанном сценарии получает non-null.

Вопрос 5 из 30

Как превратить неявное предположение в проверяемый контракт «Лямбда для Java SAM»?

// Сохраните назначение фрагмента, но укрепите его контракт.
// Java API: void onReady(Runnable action)
fun register(api: JavaApi) {
    api.onReady { println("ready") }
}

Добавить локальную обработку результата, потому что лямбда сначала превращается в Thread и только затем в Runnable. Сохранить API и считать достаточным условие: Преобразование работает только для методов, возвращающих значение. Ограничиться поясняющим комментарием о том, что компилятор вызывает onReady немедленно и передаёт результат println. Зафиксировать текущее поведение регрессионным тестом: Kotlin наследует лямбду от любого Java-интерфейса независимо от числа методов. При публичном межъязыковом callback API предпочитать функциональный интерфейс с ясным именем и исключительной политикой.

Вопрос 6 из 30

Что проверить отдельно, чтобы не принять «Статический фасад companion object» за универсальное правило?

`@JvmOverloads` создаёт только хвостовые перегрузки для параметров по умолчанию и может столкнуться с существующими сигнатурами. Проверить, сохраняется ли контракт, когда аннотация делает метод inline во всех JVM-вызовах. Отдельно воспроизвести случай, в котором метод становится synchronized на уровне класса. Зафиксировать сценарий, где ожидается: Метод становится top-level и удаляется из Kotlin companion object. Добавить граничный тест на утверждение: Она превращает возвращаемый String в platform type внутри Kotlin.

Вопрос 7 из 30

Какой принцип лежит в основе поведения «Null на реальной Java-границе»?

// На ревью требуется объяснить причину поведения.
// Java stub возвращает null вопреки неаннотированной сигнатуре
val api = mock<LegacyApi> { on { findName() } doReturn null }
val result = runCatching { length(api) }

Механика примера описывается утверждением: Замокировать `String.length`, чтобы он возвращал ноль для null. Interop-тесты должны пересекать реальную языковую границу: Java fixture, nullability-аннотации, перегрузки и имена в байткоде. Ключевым считают контракт: Проверить только успешную строку: Java-компилятор уже исключает null. Причина результата в том, что отключить strict nullability и считать отсутствие предупреждений тестом. Из правил языка или API следует, что сравнить Kotlin-исходник с декомпилированным Java, не выполняя граничный случай.

Вопрос 8 из 30

Как превратить неявное предположение в проверяемый контракт «Interop-адаптер как граница»?

// Сохраните назначение фрагмента, но укрепите его контракт.
import kotlinx.coroutines.*
class JavaClientAdapter(private val client: LegacyClient) {
    suspend fun fetch(id: String): Item = withContext(Dispatchers.IO) {
        val raw = requireNotNull(client.fetch(id)) { "LegacyClient returned null for $id" }
        raw.toDomain()
    }
}

Ограничиться поясняющим комментарием о том, что после withContext Java DTO автоматически становится immutable. Спрятать участок за вспомогательной функцией, сохранив предположение: Слой устраняет необходимость тестировать null и исключения Java API. Зафиксировать thread-safety клиента, ограничить параллелизм и возвращать Kotlin-доменную модель без Java mutable collections. Добавить локальную обработку результата, потому что адаптер гарантирует потокобезопасность LegacyClient без знания его контракта. Зафиксировать текущее поведение регрессионным тестом: Он нужен главным образом для создания отдельного потока на каждый Java-объект.

Вопрос 9 из 30

Как укрепить «Неаннотированный Java-результат», не переписывая соседние модули?

// Сохраните назначение фрагмента, но укрепите его контракт.
// Java: String findName();  // без аннотации nullability
fun length(api: LegacyApi): Int {
    val name = api.findName()
    return name.length
}

Оставить структуру прежней, документировав утверждение: Риск ограничен reflection; обычный прямой вызов в показанном сценарии получает non-null. Оставить реализацию без изменений и закрепить тестом предположение: Платформенный тип проверяется только при сборке Java-класса и затем безопасен. Перенести проверку в вызывающий код, исходя из того, что kotlin подставит пустую строку, если Java вернёт null. Добавить защитную проверку перед фрагментом, поскольку код не компилируется, потому что любой Java String автоматически становится String. Добавить поддерживаемые nullability-аннотации в Java API или проверить результат на Kotlin-границе и преобразовать его в честный доменный тип.

Вопрос 10 из 30

Где поведение «Лямбда для Java SAM» требует отдельной проверки?

Проверить границу полезности утверждения: Kotlin наследует лямбду от любого Java-интерфейса независимо от числа методов. Добавить тест на состояние, при котором лямбда сначала превращается в Thread и только затем в Runnable. Перегрузки с несколькими SAM-типами одинаковой формы могут сделать вызов лямбды неоднозначным без явного типа. Отдельно проверить предположение, что компилятор вызывает onReady немедленно и передаёт результат println. Проверить соседний случай: Преобразование работает только для методов, возвращающих значение.

Вопрос 11 из 30

Какую обратную сторону имеет решение для «Статический фасад companion object»: Добавлять аннотацию только после проверки Java-вызова и бинарного контракта, а не украшать весь Kotlin API автоматически?

Обратная сторона изменения состоит в том, что метод становится synchronized на уровне класса. Решение оправдано лишь при условии: Она превращает возвращаемый String в platform type внутри Kotlin. Java-удобство улучшает смешанный проект, но увеличивает поверхность байткода и цену будущего изменения сигнатуры. Новый риск связан с тем, что аннотация делает метод inline во всех JVM-вызовах. Компромисс состоит в утверждении: Метод становится top-level и удаляется из Kotlin companion object.

Вопрос 12 из 30

Зачем здесь `@Throws`?

// Проследите фактическое выполнение без изменения кода.
class Loader {
    @Throws(java.io.IOException::class)
    fun load(path: String): String = java.io.File(path).readText()
}

Она меняет тип исключения на RuntimeException. Она добавляет `throws IOException` в JVM-сигнатуру для Java-потребителя. Она перехватывает IOException и возвращает пустую строку. Она заставляет Kotlin-компилятор требовать try/catch у каждого вызова. Без неё IOException невозможно бросить из Kotlin-функции.

Вопрос 13 из 30

Где поведение «Interop-адаптер как граница» требует отдельной проверки?

Добавить тест на состояние, при котором адаптер гарантирует потокобезопасность LegacyClient без знания его контракта. Отдельно проверить предположение, что после withContext Java DTO автоматически становится immutable. Добавить регрессию на гипотезу: Слой устраняет необходимость тестировать null и исключения Java API. Если LegacyClient хранит thread-affine состояние, перенос каждого вызова на произвольный IO-поток может нарушить его контракт. Проверить границу полезности утверждения: Он нужен главным образом для создания отдельного потока на каждый Java-объект.

Вопрос 14 из 30

Какой дополнительный сценарий нужен для «Неаннотированный Java-результат»?

Проверить крайний ввод, при котором kotlin подставит пустую строку, если Java вернёт null. Считать опасной границей ситуацию, где код не компилируется, потому что любой Java String автоматически становится String. Зафиксировать сценарий, где ожидается: Платформенный тип проверяется только при сборке Java-класса и затем безопасен. Аннотации на generic-аргументах и массивах требуют корректных TYPE_USE targets; иначе часть вложенной nullability теряется. Добавить граничный тест на утверждение: Риск ограничен reflection; обычный прямой вызов в показанном сценарии получает non-null.

Вопрос 15 из 30

Какова практическая цена решения «Лямбда для Java SAM»: При публичном межъязыковом callback API предпочитать функциональный интерфейс с ясным именем и исключительной политикой?

Цена упрощения проявится, если преобразование работает только для методов, возвращающих значение. Лямбда уменьшает шаблонный код, но анонимный callback сложнее снять с регистрации, если API сравнивает экземпляры. Главный риск формулируют так: Kotlin наследует лямбду от любого Java-интерфейса независимо от числа методов. После внедрения придётся исходить из того, что лямбда сначала превращается в Thread и только затем в Runnable. Практическое ограничение подхода: Компилятор вызывает onReady немедленно и передаёт результат println.

Вопрос 16 из 30

Что меняет `@JvmStatic` для Java-потребителя?

// Проследите фактическое выполнение без изменения кода.
class Greeter {
    companion object {
        @JvmStatic fun hello(name: String) = "Hi, $name"
    }
}

Аннотация делает метод inline во всех JVM-вызовах. Метод становится top-level и удаляется из Kotlin companion object. Метод становится synchronized на уровне класса. Java получает статический `Greeter.hello(...)` рядом с методом companion object. Она превращает возвращаемый String в platform type внутри Kotlin.

Вопрос 17 из 30

Какое правило нужно применить, чтобы объяснить «Checked-контракт для Java»?

// На ревью требуется объяснить причину поведения.
class Loader {
    @Throws(java.io.IOException::class)
    fun load(path: String): String = java.io.File(path).readText()
}

Такой результат объясняют тем, что она меняет тип исключения на RuntimeException. Ключевым считают контракт: Она перехватывает IOException и возвращает пустую строку. Kotlin не проверяет checked exceptions, но `@Throws` важна для Java и некоторых Objective-C/Swift границ. Наблюдаемое поведение выводят из того, что она заставляет Kotlin-компилятор требовать try/catch у каждого вызова. Из правил языка или API следует, что без неё IOException невозможно бросить из Kotlin-функции.

Вопрос 18 из 30

Как сделать ответственность во фрагменте «Null на реальной Java-границе» понятной следующему разработчику?

// Сохраните назначение фрагмента, но укрепите его контракт.
// Java stub возвращает null вопреки неаннотированной сигнатуре
val api = mock<LegacyApi> { on { findName() } doReturn null }
val result = runCatching { length(api) }

Ограничиться поясняющим комментарием о том, что проверить только успешную строку: Java-компилятор уже исключает null. Добавить маленький Java-модуль-потребитель в сборку и compile-test для наиболее важных публичных сигнатур. Оставить реализацию без изменений и закрепить тестом предположение: Отключить strict nullability и считать отсутствие предупреждений тестом. Спрятать участок за вспомогательной функцией, сохранив предположение: Сравнить Kotlin-исходник с декомпилированным Java, не выполняя граничный случай. Перенести проверку в вызывающий код, исходя из того, что замокировать `String.length`, чтобы он возвращал ноль для null.

Вопрос 19 из 30

Какой побочный эффект существеннее остальных после правки «Неаннотированный Java-результат»: Добавить поддерживаемые nullability-аннотации в Java API или проверить результат на Kotlin-границе и преобразовать его в честный доменный тип?

Строгая обработка на границе увеличивает код адаптера, но локализует NPE и не заражает платформенными типами доменную модель. Обратная сторона изменения состоит в том, что платформенный тип проверяется только при сборке Java-класса и затем безопасен. После правки останется ограничение: Риск ограничен reflection; обычный прямой вызов в показанном сценарии получает non-null. Новый риск связан с тем, что код не компилируется, потому что любой Java String автоматически становится String. Решение оправдано лишь при условии: Kotlin подставит пустую строку, если Java вернёт null.

Вопрос 20 из 30

Почему лямбда допустима вместо `Runnable`?

// Проследите фактическое выполнение без изменения кода.
// Java API: void onReady(Runnable action)
fun register(api: JavaApi) {
    api.onReady { println("ready") }
}

Преобразование работает только для методов, возвращающих значение. Компилятор вызывает onReady немедленно и передаёт результат println. Java SAM-интерфейс имеет один абстрактный метод, и Kotlin выполняет SAM-преобразование лямбды. Kotlin наследует лямбду от любого Java-интерфейса независимо от числа методов. Лямбда сначала превращается в Thread и только затем в Runnable.

Вопрос 21 из 30

Почему поведение «Статический фасад companion object» не является случайностью?

// На ревью требуется объяснить причину поведения.
class Greeter {
    companion object {
        @JvmStatic fun hello(name: String) = "Hi, $name"
    }
}

Здесь действует следующее правило: Аннотация делает метод inline во всех JVM-вызовах. Наблюдаемое поведение выводят из того, что метод становится top-level и удаляется из Kotlin companion object. Такой результат объясняют тем, что метод становится synchronized на уровне класса. JVM-аннотации управляют формой байткода и удобством Java API: `@JvmStatic`, `@JvmField`, `@JvmName`, `@JvmOverloads`, `@Throws` решают разные задачи. Ключевым считают контракт: Она превращает возвращаемый String в platform type внутри Kotlin.

Вопрос 22 из 30

Какую точечную правку стоит принять на ревью фрагмента «Checked-контракт для Java»?

// Сохраните назначение фрагмента, но укрепите его контракт.
class Loader {
    @Throws(java.io.IOException::class)
    fun load(path: String): String = java.io.File(path).readText()
}

Передать ответственность владельцу вызова, предполагая, что без неё IOException невозможно бросить из Kotlin-функции. Оставить реализацию без изменений и закрепить тестом предположение: Она заставляет Kotlin-компилятор требовать try/catch у каждого вызова. Оставить структуру прежней, документировав утверждение: Она перехватывает IOException и возвращает пустую строку. Документировать и типизировать ожидаемые ошибки на публичной границе; для Kotlin API рассмотреть Result или доменный sealed-тип. Обернуть операцию проверкой и не менять основной контракт: Она меняет тип исключения на RuntimeException.

Вопрос 23 из 30

Какой тест лучше всего защищает край контракта «Null на реальной Java-границе»?

Отдельно проверить предположение, что проверить только успешную строку: Java-компилятор уже исключает null. Kotlin mock может не воспроизвести Java-аннотации и overload resolution; часть ошибок видна только в настоящем Java source set. Зафиксировать сценарий, где ожидается: Отключить strict nullability и считать отсутствие предупреждений тестом. Добавить регрессию на гипотезу: Сравнить Kotlin-исходник с декомпилированным Java, не выполняя граничный случай. Проверить крайний ввод, при котором замокировать `String.length`, чтобы он возвращал ноль для null.

Вопрос 24 из 30

Какую обратную сторону имеет решение для «Interop-адаптер как граница»: Зафиксировать thread-safety клиента, ограничить параллелизм и возвращать Kotlin-доменную модель без Java mutable collections?

Новый риск связан с тем, что после withContext Java DTO автоматически становится immutable. Обратная сторона изменения состоит в том, что слой устраняет необходимость тестировать null и исключения Java API. Компромисс состоит в утверждении: Адаптер гарантирует потокобезопасность LegacyClient без знания его контракта. Практическое ограничение подхода: Он нужен главным образом для создания отдельного потока на каждый Java-объект. Дополнительный слой увеличивает число типов, но резко уменьшает область, где нужно помнить о слабых гарантиях legacy API.

Вопрос 25 из 30

На какой контракт языка или библиотеки опирается «Лямбда для Java SAM»?

// На ревью требуется объяснить причину поведения.
// Java API: void onReady(Runnable action)
fun register(api: JavaApi) {
    api.onReady { println("ready") }
}

SAM conversion создаёт реализацию функционального интерфейса; для Kotlin-контрактов можно использовать `fun interface`. Контракт здесь понимают так: Лямбда сначала превращается в Thread и только затем в Runnable. Поведение связывают с правилом: Kotlin наследует лямбду от любого Java-интерфейса независимо от числа методов. Объяснение опирается на утверждение: Компилятор вызывает onReady немедленно и передаёт результат println. Причину поведения формулируют так: Преобразование работает только для методов, возвращающих значение.

Вопрос 26 из 30

Что следует изменить прежде всего во фрагменте «Статический фасад companion object»?

// Сохраните назначение фрагмента, но укрепите его контракт.
class Greeter {
    companion object {
        @JvmStatic fun hello(name: String) = "Hi, $name"
    }
}

Добавлять аннотацию только после проверки Java-вызова и бинарного контракта, а не украшать весь Kotlin API автоматически. Обернуть операцию проверкой и не менять основной контракт: Метод становится top-level и удаляется из Kotlin companion object. Передать ответственность владельцу вызова, предполагая, что аннотация делает метод inline во всех JVM-вызовах. Зафиксировать текущее поведение регрессионным тестом: Она превращает возвращаемый String в platform type внутри Kotlin. Добавить локальную обработку результата, потому что метод становится synchronized на уровне класса.

Вопрос 27 из 30

Какой пограничный сценарий обязательно добавить к проверкам «Checked-контракт для Java»?

Добавить тест на состояние, при котором она меняет тип исключения на RuntimeException. Отдельно воспроизвести случай, в котором она заставляет Kotlin-компилятор требовать try/catch у каждого вызова. Java-метод может бросить checked-исключение, не объявленное в Kotlin-типе функции; caller обязан знать реальный контракт библиотеки. Проверить границу полезности утверждения: Она перехватывает IOException и возвращает пустую строку. Проверить соседний случай: Без неё IOException невозможно бросить из Kotlin-функции.

Вопрос 28 из 30

Какую обратную сторону имеет решение для «Null на реальной Java-границе»: Добавить маленький Java-модуль-потребитель в сборку и compile-test для наиболее важных публичных сигнатур?

Практическое ограничение подхода: Проверить только успешную строку: Java-компилятор уже исключает null. Обратная сторона изменения состоит в том, что отключить strict nullability и считать отсутствие предупреждений тестом. Решение оправдано лишь при условии: Замокировать `String.length`, чтобы он возвращал ноль для null. Межъязыковые compile-tests медленнее обычных unit-тестов, зато ловят поломки API, которые внутренний Kotlin-код не замечает. Компромисс состоит в утверждении: Сравнить Kotlin-исходник с декомпилированным Java, не выполняя граничный случай.

Вопрос 29 из 30

Почему адаптер — подходящая архитектурная граница?

// Проследите фактическое выполнение без изменения кода.
import kotlinx.coroutines.*
class JavaClientAdapter(private val client: LegacyClient) {
    suspend fun fetch(id: String): Item = withContext(Dispatchers.IO) {
        val raw = requireNotNull(client.fetch(id)) { "LegacyClient returned null for $id" }
        raw.toDomain()
    }
}

Адаптер гарантирует потокобезопасность LegacyClient без знания его контракта. Он локализует platform types, блокирующий вызов и преобразование Java DTO, не распространяя эти риски по доменному коду. После withContext Java DTO автоматически становится immutable. Слой устраняет необходимость тестировать null и исключения Java API. Он нужен главным образом для создания отдельного потока на каждый Java-объект.

Вопрос 30 из 30

Где находится риск в Kotlin-коде?

// Проследите фактическое выполнение без изменения кода.
// Java: String findName();  // без аннотации nullability
fun length(api: LegacyApi): Int {
    val name = api.findName()
    return name.length
}

`name` имеет платформенный тип: компилятор разрешит `length`, но Java может вернуть null и вызвать NPE во время выполнения. Риск ограничен reflection; обычный прямой вызов в показанном сценарии получает non-null. Kotlin подставит пустую строку, если Java вернёт null. Платформенный тип проверяется только при сборке Java-класса и затем безопасен. Код не компилируется, потому что любой Java String автоматически становится String.