Сводим Java c Kotlin: Interoperability | OTUS
⚡Подписка от OTUS!
Собери свой пул курсов на выгодных условиях. Подробности в чате →
Написать в чат

Курсы

Программирование
Unity Game Developer. Basic
-15%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-6%
Разработчик C#
-8%
Алгоритмы и структуры данных
-8%
Backend-разработчик на PHP
-8%
JavaScript Developer. Professional
-9%
iOS Developer. Professional
-8%
Базы данных
-12%
C# ASP.NET Core разработчик
-6%
Python Developer. Basic
-10%
Java Developer. Professional Web-разработчик на Python Android Developer. Basic PostgreSQL Software Architect Reverse-Engineering. Professional Kotlin Backend Developer React.js Developer VOIP инженер Нереляционные базы данных Scala-разработчик Супер-практикум по использованию и настройке GIT IoT-разработчик JavaScript Developer. Basic Advanced Fullstack JavaScript developer Unity Game Developer. Professional Супер-интенсив Azure
Инфраструктура
Супер-интенсив "Версионирование и командная работа с помощью Git"
-30%
Administrator Linux. Professional
-5%
Супер-интенсив «CI/CD или Непрерывная поставка с Docker и Kubernetes»
-30%
Разработчик программных роботов (RPA) на базе UiPath и PIX
-6%
Administrator Linux. Advanced
-8%
Infrastructure as a code in Ansible
-12%
Network engineer
-4%
MS SQL Server Developer
-8%
Cloud Solution Architecture Highload Architect Разработчик голосовых ассистентов и чат-ботов Мониторинг и логирование: Zabbix, Prometheus, ELK Супер-практикум по работе с протоколом BGP Супер - интенсив по паттернам проектирования Супер - интенсив по Kubernetes Архитектор сетей Супер-интенсив «IaC Ansible»
Специализации Курсы в разработке Подготовительные курсы
+7 499 938-92-02

Сводим Java c Kotlin: Interoperability

Предположим, что вы являетесь Android-разработчиком, который переходит на Kotlin и вы желаете зайти дальше уровня data-классов, планируя писать на Kotlin более сложные классы для фрагментов, активити, viewmodel-, interactor-, presenter-, repository- и прочих классов в зависимости от вашей архитектуры.

Допустим, в перспективе вы думаете полностью избавиться от Джавы в проекте. Все бы ничего, но сначала понадобится пройти довольно длинный путь устранения конфликтов между этими двумя языками.

Так как язык программирования Котлин изначально проектировался как JVM-язык, который полностью совместим с Java, вы без особых сложностей сможете наследоваться от существующих Джава-классов, а также обращаться к ним и использовать Java-аннотации к вашим методам и Kotlin-классам.

Но следует учесть, что есть несколько камней преткновения, которые образовались под влиянием, если можно так сказать, идеологических различий между 2-мя языками. О некоторых из них мы и поговорим.

GoingStatic

К примеру, в Kotlin отсутствует ключевое слово static, и с этим нужно просто смириться.

Но это не беда, ведь в нашем распоряжении есть companionobject. Речь идет о механизме объявления объекта внутри класса, причем этот механизм способен содержать внутри константы и методы, которые со стороны Джава будут синтаксически доступны, при этом в том же виде, как и статические поля либо Java-методы. Однако для того, чтобы при компиляции сгенерировались и статический метод класса, в котором, кстати, находится этот объект, да и метод этого объекта сам по себе, следует пометить его как @JvmStatic (по дефолту без этой аннотации метод companion-объекта является доступным посредством ссылки на Companion-инстанс).

Тему companionobjects, а также вопросы создания синглтонов и objectexpressions в Котлин подробно раскрывает вот эта страница документации.

Однако прежде, чем вы заключите ваши константы в companionobject-ы по всему проекту, учтите, что такие объекты не так уж дешевы, как это может показаться. Именно поэтому всем, кто планирует переходить на Котлин, рекомендуется ознакомиться с блоком статей «Kotlin’shiddencosts» (part 1, part 2, part 3). Эти статьи открывают обратную сторону синтаксического сахара с точки зрения байткода. Особое внимание следует обратить на советы по применению inline-функций для оптимизации производительности лямбда-выражений. Представляют интерес и рекомендации относительно того, как избежать избыточность автоупаковки/автораспаковки «под капотом».

Коллекции

Если мы говорим о коллекциях, то тут Kotlin полностью полагается на классы стандартной Java-библиотеки, расширяя их возможности посредством дополнительных функций для объявления (listOf(), mapOf(), etc), а также их модификаций и преобразований. Вообще, они относительно часто оказываются полезны и удобны в применении, поэтому с коллекциями в Kotlin в целом все неплохо и довольно прозрачно. По крайней мере, почти…

Также обратите внимание, что List, Map и Set являются алиасами для неизменяемых JDK-реализаций коллекций, а попытки поменять их содержимое обернутся UnsupportedOperationException, что, в принципе, логично.

Generics

Обобщения в Котлин тоже поддерживаются, однако есть важные различия в их реализации между 2-мя языками. Пренебрежение этими различиями способно привести вас к непредвиденным конфузным ситуациям. Вообще, эта разница подробно описана в документации и во многих тематических статьях. Вот некоторые материалы, неплохо раскрывающие ключевые для дженериков концепции ковариантности, инвариантности и контравариантности: • https://kotlinlang.org/docs/reference/generics.html; • https://proandroiddev.com/understanding-generics-and-variance-in-kotlin-714c14564c47; • https://typealias.com/guides/illustrated-guide-covariance-contravariance/.

Источник

Не пропустите новые полезные статьи!

Спасибо за подписку!

Мы отправили вам письмо для подтверждения вашего email.
С уважением, OTUS!

Автор
0 комментариев
Для комментирования необходимо авторизоваться