Сводим 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-библиотеки, расширяя их возможности посредством дополнительных функций для объявления
Также обратите внимание, что 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/.
