Kotlin 2.5.0 introduit des blocs et des extensions companion à titre expérimental

JetBrains a détaillé de nouvelles évolutions apportées au mécanisme companion de Kotlin à partir de la version 2.5.0. Ces mises à jour introduisent des blocs companion et des extensions companion expérimentaux, conçus pour améliorer la compilation des membres statiques et étendre l'interopérabilité dans les projets multiplateformes.

Blocs companion et compilation statique

Historiquement, Kotlin s'appuyait sur des objets companion pour gérer les fonctionnalités au niveau des classes, telles que les méthodes fabriques, les utilitaires et les constantes. À partir de Kotlin 2.5.0, les développeurs peuvent utiliser une syntaxe de bloc companion à la place. Bien que très proche sur le plan syntaxique, le bloc companion modifie la manière dont le code est compilé. Sur la JVM, ces blocs sont directement compilés sous forme de membres statiques plutôt que d'engendrer des instances d'objets companion intermédiaires. Ce changement permet aux projets Kotlin Multiplatform de définir des membres de blocs companion attendus dans le code commun et de les concrétiser à l'aide de classes Java standard contenant des membres statiques.

Extension de classes existantes avec les extensions

Kotlin 2.5.0 introduit également des extensions companion expérimentales, permettant de déclarer de nouveaux membres de type statique sur des classes ou interfaces existantes. Cette possibilité s'applique indépendamment du fait que le type ciblé ait été conçu à l'origine en Kotlin ou en Java, et qu'il possède déjà ou non un objet companion.

Options du compilateur et limites de compatibilité

Ces deux fonctionnalités étant expérimentales, elles nécessitent des options de compilation explicites. Les développeurs peuvent activer les blocs companion à l'aide du fanion `-Xcompanion-blocks`, tandis que l'activation des extensions requiert `-Xcompanion-blocks-and-extensions`. L'utilisation des extensions companion amène le compilateur à générer des binaires de pré-publication, ce qui empêche les bibliothèques qui les emploient d'être consommées comme dépendances stables tant que la fonctionnalité n'est pas stabilisée.

Les objets companion existants restent entièrement pris en charge et s'avèrent nécessaires lorsque le companion doit implémenter une interface spécifique, dans la mesure où les blocs companion ne produisent pas d'instance de classe distincte. JetBrains précise que les bases de code actuelles ne nécessitent aucune migration, bien que le retrait du mot-clé `object` permette de transformer les objets companion standards en blocs companion après recompilation.

Illustration éditoriale générée par IA ; ce n’est pas une photographie documentaire.

Source: The Companions to Come