Releases

Publication de Kotlin 1.6.20

Read this post in other languages:
English, 日本語, 한국어, Deutsch, 简体中文

Nous avons publié Kotlin 1.6.20. Cette nouvelle version donne un aperçu des futures fonctionnalités du langage et apporte la structure hiérarchique par défaut pour les projets multiplateformes et des améliorations de performances pour les plateformes JVM, JS et Native.

Cet article présente les améliorations suivantes et fournit une liste complète des autres évolutions :


Comment faire la mise à jour

Si vous utilisez IntelliJ IDEA ou Android Studio, vous pouvez choisir la mise à jour automatique de Kotlin.

Mise à jour vers Kotlin 1.6.20

Améliorations majeures

Prototype de récepteurs de contexte pour Kotlin/JVM

Avec Kotlin 1.6.20, vous n’êtes plus limité à un récepteur. Si besoin, vous pouvez rendre les fonctions, propriétés et classes dépendantes du contexte (ou contextuelles) en ajoutant des récepteurs de contexte à leur déclaration. Les caractéristiques du comportement d’une déclaration contextuelle sont les suivantes :

  • Elle requiert que tous les récepteurs de contexte déclarés soient présents en tant que récepteurs implicites dans la portée de l’appelant.
  • Elle intègre les récepteurs de contexte déclarés dans sa portée en tant que récepteurs implicites.

Pour activer les récepteurs de contexte dans votre projet, utilisez l’option de compilateur -Xcontext-receivers. Vous pouvez trouver une description de la fonctionnalité et sa syntaxe dans le KEEP.

Veuillez noter que l’implémentation est un prototype :

  • Lorsque -Xcontext-receivers est activé, le compilateur produit des binaires de préversion qui ne peuvent pas être utilisés dans le code de production.
  • La prise en charge des récepteurs de contexte par l’IDE est actuellement minimale.

Types définitivement non-nullables

Pour assurer une meilleure interopérabilité lors de l’extension de classes et d’interfaces Java génériques, Kotlin 1.6.20 permet de marquer un paramètre de type générique comme définitivement non-nullable sur le site d’utilisation avec la nouvelle syntaxe T & ; Any. La forme syntaxique provient d’une notation de types d’intersection. Elle est maintenant limitée à un paramètre de type avec des limites supérieures nullables sur le côté gauche de & et non-nullables Any sur le côté droit :

Définissez la version du langage sur 1.7 pour activer la fonctionnalité :

Pour en savoir plus sur les types définitivement non-nullables, consultez le KEEP.

Veuillez noter que les types définitivement non-nullables sont encore en version bêta. Ils sont quasiment stables, mais des étapes de migration pourraient être nécessaires à l’avenir. Nous ferons en sorte que vous ayez le moins de modifications possibles à effectuer.

Prise en charge de la compilation parallèle d’un module unique dans le backend de la JVM

Dans Kotlin 1.6.20, nous avons ajouté le mode expérimental du backend IR de la JVM pour compiler tous les fichiers d’un module en parallèle. La compilation parallèle permet de réduire la durée totale de compilation jusqu’à 15 %.

Activez le mode backend parallèle expérimental avec l’option de compilateur -Xbackend-threads. Utilisez les arguments suivants pour cette option :

  • N est égal au nombre de threads que vous souhaitez utiliser. Il ne doit pas être supérieur à votre nombre de cœurs de processeur, sinon la parallélisation cesse d’être efficace en raison du changement de contexte entre les threads
  • 0 pour utiliser un thread pour chaque cœur de processeur.

Gradle peut exécuter des tâches en parallèle, mais ce type de parallélisation est peu utile lorsqu’un projet (ou une partie importante d’un projet) ne représente qu’une seule grande tâche du point de vue de Gradle. Pour un très gros module monolithique, il est préférable d’utiliser la compilation parallèle pour compiler plus rapidement. Si votre projet est composé de nombreux petits modules et que le build est parallélisé par Gradle, ajouter une couche de parallélisation supplémentaire peut nuire aux performances en raison du changement de contexte.

La compilation parallèle n’est pas exempte de contraintes :

  • Elle ne fonctionne pas avec kapt car kapt désactive le backend IR.
  • Par conception, elle nécessite plus de tas JVM. La quantité de tas est proportionnelle au nombre de threads.

Compilation incrémentale pour les binaires de développement avec le compilateur Kotlin/JS IR

Nous introduisons un nouveau mode compilation incrémentale afin de rendre le développement Kotlin/JS avec le compilateur IR plus efficace.

Lors de la création de binaires de développement avec la tâche Gradle compileDevelopmentExecutableKotlinJs dans ce mode, le compilateur met en cache les résultats des compilations précédentes au niveau du module. Il utilise les résultats de compilation mis en cache pour les fichiers source inchangés lors des compilations suivantes, ce qui permet de les exécuter plus rapidement, notamment pour les petites modifications. Veuillez noter que cette amélioration concerne uniquement le processus de développement (raccourcissement du cycle modification-build-débogage) et n’affecte pas la construction des artefacts de production.

Pour activer la compilation incrémentale pour les binaires de développement, ajoutez la ligne suivante au fichier gradle.properties du projet :

Dans nos projets tests, ce nouveau mode a permis d’accélérer la compilation incrémentale jusqu’à 30 %. En revanche, le build propre devenait plus lent à cause de la nécessité de créer et de préparer les caches.

Améliorations des performances de Kotlin/Native

Kotlin 1.6.20 améliore certaines performances et résout des bugs affectant la LLVM IR que Kotlin génère. D’après les benchmarks effectués sur nos projets internes, nous avons obtenu en moyenne les améliorations de performance suivantes :

  • Réduction de 15 % du temps d’exécution
  • Réduction de 20 % de la taille du code des binaires de version et de débogage
  • Réduction de 26 % du temps de compilation des binaires de version

Le temps de compilation d’un binaire de débogage sur un grand projet interne a également été réduit de 10 %.

Pour parvenir à ces résultats, nous avons implémenté une initialisation statique pour certains des objets synthétiques générés par le compilateur, amélioré la manière de structurer les IR LLVM pour chaque fonction, et optimisé les caches du compilateur.

Prise en charge de la structure hiérarchique pour les projets multiplateformes

Kotlin 1.6.20 apporte la prise en charge de la structure hiérarchique par défaut. Depuis son introduction dans Kotlin 1.4.0, nous avons considérablement amélioré le frontend et rendu l’importation de l’IDE stable.

Auparavant, il y avait deux manières d’ajouter du code dans un projet multiplateforme. La première consistait à l’insérer dans un ensemble de sources spécifiques à une plateforme, ce qui se limitait à une cible et ne pouvait pas être réutilisé par d’autres plateformes. La seconde est d’utiliser un ensemble de sources commun partagé entre toutes les plateformes actuellement prises en charge par Kotlin.

Désormais, vous pouvez partager le code source entre plusieurs cibles natives similaires qui réutilisent une grande partie de la logique commune et des API tierces. La technologie fournira les dépendances correctes par défaut et trouvera l’API exacte disponible dans le code partagé. Cela permet d’éviter une configuration de build complexe et de devoir utiliser des solutions alternatives pour que l’IDE prenne en charge le partage des ensembles de sources entre les cibles natives. Cela aide également à empêcher les utilisations d’API non sécurisées destinées à une cible différente.

La technologie sera aussi utile aux auteurs de bibliothèques, car une structure de projet hiérarchique permet de publier et d’utiliser des bibliothèques avec des API communes pour un sous-ensemble de cibles.
Par défaut, les bibliothèques publiées avec une structure de projet hiérarchique sont uniquement compatibles avec des projets de structure hiérarchique. Apprenez-en plus sur la compatibilité entre projet et bibliothèque.

Amélioration du partage du code dans votre projet

Sans prise en charge de la structure hiérarchique, il n’y a pas de moyen simple de partager du code entre certaines cibles Kotlin et d’en exclure d’autres. Un exemple courant est le partage du code entre toutes les cibles iOS et l’accès à des dépendances spécifiques à iOS, comme Foundation.

La prise en charge de la structure hiérarchique facilite le partage de code. Dans la nouvelle structure, les ensembles de sources forment une hiérarchie. Vous pouvez utiliser les fonctionnalités de langage spécifiques à la plateforme et les dépendances disponibles pour chaque cible pour laquelle un ensemble de sources donné est compilé.

Prenons par exemple un projet multiplateforme typique avec deux cibles : iosArm64 et iosX64 pour les appareils et les simulateurs iOS. Les outils Kotlin comprennent que les deux cibles ont la même fonction et vous permettent d’accéder à cette fonction à partir de l’ensemble de sources intermédiaires, iosMain.

La chaîne d’outils Kotlin fournit les dépendances correctes par défaut, comme Kotlin/Native stdlib ou les bibliothèques natives. De plus, les outils Kotlin feront le maximum pour trouver exactement la surface d’API disponible dans le code partagé. Cela permet d’éviter des cas tels que l’utilisation d’une fonction spécifique à macOS dans du code partagé pour Windows par exemple.

Plus d’opportunités pour les auteurs de bibliothèque

Lorsqu’une bibliothèque multiplateforme est publiée, l’API de ses ensembles de sources intermédiaires est désormais publiée correctement à ses côtés, ce qui la rend disponible pour les utilisateurs. Là encore, la chaîne d’outils Kotlin déterminera automatiquement l’API disponible dans l’ensemble des sources consommateur, tout en surveillant attentivement les utilisations non sécurisées, comme l’utilisation d’une API destinée à la JVM dans du code JS. En savoir plus sur le partage de code dans les bibliothèques.

Configuration et installation

À partir de Kotlin 1.6.20, tous vos nouveaux projets multiplateformes auront une structure de projet hiérarchique. Aucune autre configuration n’est nécessaire.

  • Si vous l’avez déjà activée manuellement, vous pouvez supprimer les options obsolètes à partir de gradle.properties :
  • Avec Kotlin 1.6.20, nous vous recommandons d’utiliser Android Studio 2021.1.1 (Bumblebee) ou une version ultérieure pour bénéficier de la meilleure expérience possible.
  • Vous pouvez également désactiver cette option. Pour désactiver la prise en charge de la structure hiérarchique, définissez les options suivantes dans gradle.properties :

Liste complète des améliorations

Langage

Kotlin/JVM

Kotlin/Native

Kotlin Multiplatform

Kotlin/JS

Sécurité

Gradle

Comment installer Kotlin 1.6.20

Si vous utilisez déjà IntelliJ IDEA ou Android Studio, votre IDE vous proposera de faire la mise à jour vers Kotlin 1.6.20 automatiquement. Vous pouvez également faire la mise à jour manuellement en suivant ces instructions.

Vous pouvez télécharger les dernières versions des IDE suivants pour bénéficier d’une prise en charge étendue pour Kotlin :

  • IntelliJ IDEA : pour développer des applications Kotlin pour différentes plateformes.
  • Android Studio : pour le développement d’applications mobiles Android et multiplateformes.

Assurez-vous aussi de mettre à jour les bibliothèques kotlinx vers des versions compatibles et de spécifier la version 1.6.20 de Kotlin dans les scripts de build de vos projets existants.

Si vous avez besoin du compilateur en ligne de commande, téléchargez-le depuis la page Github de la version.

En cas de problème

Restez au courant des dernières fonctionnalités de Kotlin ! Inscrivez-vous en remplissant le formulaire à droite de cet article pour recevoir les actualités relatives à Kotlin.

Autres lectures et vidéos

Auteur de l’article original en anglais :

Delphine Massenhove

Andrey Polyakov

Discover more