Kotlin 1.8.0 est disponible. Cette version ajoute de nouvelles fonctions expérimentales pour JVM

Améliore l'interopérabilité Objective-C/Swift et est compatible avec Gradle 7.3

JetBrains a annoncé la disponibilité de Kotlin 1.8.0. Voici quelques nouveautés / améliorations apportées par cette version :

• Nouvelles fonctions expérimentales pour JVM : copier ou supprimer récursivement le contenu du répertoire
• Amélioration des performances de kotlin-reflect
• Nouvelle option de compilateur -Xdebug pour une meilleure expérience de débogage
• kotlin-stdlib-jdk7 et kotlin-stdlib-jdk8 fusionnés dans kotlin-stdlib
• Amélioration de l'interopérabilité Objective-C/Swift
• Compatibilité avec Gradle 7.3
  

Kotlin/JVM

A partir de la version 1.8.0, le compilateur peut générer des classes avec une version de bytecode correspondant à JVM 19. La nouvelle version du langage inclut également :

• Une option de compilateur pour désactiver la génération de cibles d'annotation JVM
• Une nouvelle option de compilateur -Xdebug pour désactiver les optimisations
• La suppression de l'ancien backend
• La prise en charge de l'annotation @Builder de Lombok
  

Possibilité de ne pas générer de cibles d'annotation TYPE_USE et TYPE_PARAMETER

Si une annotation Kotlin a TYPE parmi ses cibles Kotlin, l'annotation sera mappée à java.lang.annotation.ElementType.TYPE_USE dans sa liste de cibles d'annotation Java. C'est exactement comme la façon dont la cible TYPE_PARAMETER Kotlin est mappée à la cible Java java.lang.annotation.ElementType.TYPE_PARAMETER. C'est un problème pour les clients Android avec des niveaux d'API inférieurs à 26, qui n'ont pas ces cibles dans l'API.

À partir de Kotlin 1.8.0, vous pouvez utiliser la nouvelle option du compilateur -Xno-new-java-annotation-targets pour éviter de générer les cibles d'annotation TYPE_USE et TYPE_PARAMETER.

Une nouvelle option du compilateur pour désactiver les optimisations

Kotlin 1.8.0 ajoute une nouvelle option de compilateur -Xdebug, qui désactive les optimisations pour une meilleure expérience de débogage. Pour l'instant, l'option désactive la fonctionnalité "a été optimisée" pour les coroutines. À l'avenir, après avoir ajouté d'autres optimisations, cette option les désactivera également.

La fonctionnalité "a été optimisée" optimise les variables lorsque vous utilisez des fonctions de suspension. Cependant, il est difficile de déboguer du code avec des variables optimisées car vous ne voyez pas leurs valeurs.

Ne jamais utiliser cette option en production : la désactivation de cette fonctionnalité via -Xdebug peut entraîner des fuites de mémoire.

Suppression de l'ancien backend

Dans Kotlin 1.5.0, JetBrains a annoncé que le backend basé sur l'IR devenait Stable. Cela signifiait que l'ancien backend de Kotlin 1.4.* était obsolète. Dans Kotlin 1.8.0, JetBrains a complètement supprimé l'ancien backend. Par extension, l'éditeur a supprimé l'option du compilateur -Xuse-old-backend et l'option Gradle useOldBackend.

Prise en charge de l'annotation @Builder de Lombok

JetBrains d'expliquer : « La communauté a tellement voté pour Kotlin Lombok : sur YouTrack, les constructeurs générés (@Builder) ont été tellement votés que nous n'avons eu d'autres choix que de prendre en charge l'annotation @Builder. Nous n'avons pas encore prévu de prendre en charge les annotations @SuperBuilder ou @Tolerate, mais nous allons reconsidérer notre position si suffisamment de personnes votent pour @SuperBuilder et @Tolerate ».

Kotlin/natif

Kotlin 1.8.0 inclut des modifications de l'interopérabilité Objective-C et Swift, la prise en charge de Xcode 14.1 et des améliorations du plugin CocoaPods Gradle :

• Prise en charge de Xcode 14.1
• Amélioration de l'interopérabilité Objective-C/Swift
• Frameworks dynamiques par défaut dans le plugin CocoaPods Gradle
  

Prise en charge de Xcode 14.1

Le compilateur Kotlin/Native prend désormais en charge la dernière version stable de Xcode, 14.1. Les améliorations de compatibilité incluent les modifications suivantes :

• Il existe un nouveau préréglage watchosDeviceArm64 pour la cible watchOS qui prend en charge Apple watchOS sur les plates-formes ARM64.
• Le plugin Kotlin CocoaPods Gradle n'a plus d'intégration de bitcode pour les frameworks Apple par défaut.
• Les bibliothèques de plate-forme ont été mises à jour pour refléter les modifications apportées aux frameworks Objective-C pour les cibles Apple.
  

Amélioration de l'interopérabilité Objective-C/Swift

Pour rendre Kotlin plus interopérable avec Objective-C et Swift, trois nouvelles annotations ont été ajoutées :

• @ObjCName vous permet de spécifier un nom plus idiomatique dans Swift ou Objective-C, au lieu de renommer la déclaration Kotlin. L'annotation indique au compilateur Kotlin d'utiliser un nom Objective-C et Swift personnalisé pour cette classe, propriété, paramètre ou fonction :
  
  

  Code Kotlin :

  Sélectionner tout

  1
  2
  3
  4
  5
  6
  7
  8
  9
  @ObjCName(swiftName = "MySwiftArray") 
  class MyKotlinArray { 
      @ObjCName("index") 
      fun indexOf(@ObjCName("of") element: String): Int = TODO() 
  } 
    
  // Usage with the ObjCName annotations 
  let array = MySwiftArray() 
  let index = array.index(of: "element")

• @HiddenFromObjC vous permet de masquer une déclaration Kotlin à Objective-C : L'annotation indique au compilateur Kotlin de ne pas exporter une fonction ou une propriété vers Objective-C et, par conséquent, vers Swift. Cela peut rendre votre code Kotlin plus compatible Objective-C/Swift.
• @ShouldRefineInSwift est utile pour remplacer une déclaration Kotlin par un wrapper écrit en Swift.
  
  L'annotation demande au compilateur Kotlin de marquer une fonction ou une propriété comme swift_private dans l'API Objective-C générée. Ces déclarations reçoivent le préfixe __, ce qui les rend invisibles pour le code Swift.
  
  Vous pouvez toujours utiliser ces déclarations dans votre code Swift pour créer une API compatible avec Swift, mais elles ne seront pas suggérées par la saisie semi-automatique de Xcode, par exemple.
  

Frameworks dynamiques par défaut dans le plugin CocoaPods Gradle

À partir de Kotlin 1.8.0, les frameworks Kotlin enregistrés par le plugin CocoaPods Gradle sont liés dynamiquement par défaut. L'implémentation statique précédente était incompatible avec le comportement du plugin Kotlin Gradle.


Si vous avez un projet existant avec un type de liaison statique et que vous mettez à niveau vers Kotlin 1.8.0 (ou modifiez explicitement le type de liaison), vous pouvez rencontrer une erreur lors de l'exécution du projet. Pour résoudre ce problème, fermez votre projet Xcode et exécutez pod install dans le répertoire Podfile.


Kotlin Multiplatform : une nouvelle mise en page du jeu de sources Android

Kotlin 1.8.0 introduit une nouvelle disposition de l'ensemble de sources Android qui remplace le schéma de nommage précédent pour les répertoires, ce qui prête à confusion à plusieurs égards.

Prenons un exemple de deux répertoires androidTest créés dans la disposition actuelle. L'un est pour KotlinSourceSets et l'autre pour AndroidSourceSets :

• Ils ont une sémantique différente : androidTest de Kotlin appartient au type unitTest, tandis que celui d'Android appartient au type integrationTest.
• Ils créent une disposition SourceDirectories déroutante, car src/androidTest/java a un UnitTest et src/androidTest/kotlin a un InstrumentedTest.
• KotlinSourceSets et AndroidSourceSets utilisent un schéma de dénomination similaire pour les configurations Gradle, de sorte que les configurations résultantes d'androidTest pour les ensembles de sources de Kotlin et d'Android sont les mêmes : androidTestImplementation, androidTestApi, androidTestRuntimeOnly et androidTestCompileOnly.
  

Pour résoudre ces problèmes et d'autres problèmes existants, JetBrains a introduit une nouvelle disposition de l'ensemble de sources Android. Voici quelques-unes des principales différences entre les deux mises en page :

Schéma de nommage KotlinSourceSet :


Schéma de nommage SourceDirectories


L'emplacement du fichier AndroidManifest.xml


Kotlin/JS

Kotlin 1.8.0 stabilise le backend du compilateur JS IR et apporte de nouvelles fonctionnalités aux scripts de construction Gradle liés à JavaScript :

• Backend stable du compilateur IR JS
• Nouveaux paramètres pour signaler que yarn.lock a été mis à jour
• Ajout des cibles de test pour les navigateurs via les propriétés Gradle
• Nouvelle approche pour ajouter le support CSS à votre projet
  

Backend stable du compilateur IR JS

À partir de cette version, le backend du compilateur de représentation intermédiaire Kotlin/JS (basé sur IR) est stable. Il a fallu un certain temps pour unifier l'infrastructure des trois backends, mais ils fonctionnent désormais avec le même IR pour le code Kotlin.

En raison de la stabilité du backend du compilateur JS IR, l'ancien est désormais obsolète. La compilation incrémentielle est activée par défaut avec le compilateur stable JS IR. Si vous utilisez toujours l'ancien compilateur, JetBrains recommande de faire basculer votre projet vers le nouveau backend à l'aide de son guide de migration.

Nouveaux paramètres pour signaler que yarn.lock a été mis à jour

Si vous utilisez le gestionnaire de paquets de fils, il existe trois nouveaux paramètres Gradle spéciaux qui pourraient vous avertir si le fichier yarn.lock a été mis à jour. Vous pouvez utiliser ces paramètres lorsque vous souhaitez être averti si yarn.lock a été modifié en mode silencieux pendant le processus de génération de CI.

Ces trois nouvelles propriétés Gradle sont :

• YarnLockMismatchReport, qui spécifie comment les modifications apportées au fichier yarn.lock sont signalées. Vous pouvez utiliser l'une des valeurs suivantes :
  
  • FAIL fait échouer la tâche Gradle correspondante. C'est la valeur par défaut.
  • WARNING écrit les informations sur les modifications dans le journal des avertissements.
  • NONE désactive la création de rapports.
    
• reportNewYarnLock, qui signale explicitement le fichier yarn.lock récemment créé. Par défaut, cette option est désactivée : c'est une pratique courante de générer un nouveau fichier yarn.lock au premier démarrage. Vous pouvez utiliser cette option pour vous assurer que le fichier a été validé dans votre référentiel.
• yarnLockAutoReplace, qui remplace automatiquement yarn.lock à chaque exécution de la tâche Gradle.
  

Pour utiliser ces options, mettez à jour votre fichier de script de construction build.gradle.kts comme suit :


Ajouter des cibles de test pour les navigateurs via les propriétés Gradle

À partir de Kotlin 1.8.0, vous pouvez définir des cibles de test pour différents navigateurs directement dans le fichier de propriétés Gradle. Cela réduit la taille du fichier de script de construction car vous n'avez plus besoin d'écrire toutes les cibles dans build.gradle.kts. Vous pouvez utiliser cette propriété pour définir une liste de navigateurs pour tous les modules, puis ajouter des navigateurs spécifiques dans les scripts de génération de modules particuliers.

Par exemple, la ligne suivante dans votre fichier de propriétés Gradle exécutera le test dans Firefox et Safari pour tous les modules*: kotlin.js.browser.karma.browsers=firefox,safariNouvelle approche pour ajouter le support CSS à votre projet

Cette version fournit une nouvelle approche pour ajouter la prise en charge CSS à votre projet. JetBrains suppose que cela affectera de nombreux projets, alors n'oubliez pas de mettre à jour vos fichiers de script de construction Gradle comme décrit ci-dessous.

Avant Kotlin 1.8.0, la propriété cssSupport.enabled était utilisée pour ajouter le support CSS*: cssSupport.enabled = true.

Vous devez maintenant utiliser la méthode enabled.set() dans le bloc cssSupport{}*:


Gradle

Kotlin 1.8.0 prend entièrement en charge les versions 7.2 et 7.3 de Gradle. Vous pouvez également utiliser les versions de Gradle jusqu'à la dernière version de Gradle, mais si vous le faites, gardez à l'esprit que vous pourriez rencontrer des avertissements d'obsolescence ou que certaines nouvelles fonctionnalités de Gradle pourraient ne pas fonctionner.

Cette version apporte beaucoup de changements :

• Exposer les options du compilateur Kotlin en tant que propriétés paresseuses Gradle
• Les versions minimales prises en charge ont évoluées
• Possibilité de désactiver la stratégie de repli du démon Kotlin
• Utilisation de la dernière version de kotlin-stdlib dans les dépendances transitives
• Vérification obligatoire de l'égalité de compatibilité cible JVM des tâches de compilation Kotlin et Java associées
• Résolution des dépendances transitives des plugins Kotlin Gradle
• Dépréciations et suppressions
  

Exposer les options du compilateur Kotlin en tant que propriétés paresseuses Gradle

Pour exposer les options disponibles du compilateur Kotlin en tant que propriétés paresseuses Gradle et pour mieux les intégrer dans les tâches Kotlin, JetBrains a apporté de nombreuses modifications :

• Les tâches de compilation ont la nouvelle entrée compilerOptions, qui est similaire aux kotlinOptions existantes mais utilise Property de l'API Gradle Properties comme type de retour*:
  

  Code Kotlin :

  Sélectionner tout

  1
  2
  3
  4
  5
  tasks.named("compileKotlin", org.jetbrains.kotlin.gradle.tasks.KotlinJvmCompile::class.java) { 
      compilerOptions { 
          useK2.set(true) 
      } 
  }

• Les tâches des outils Kotlin KotlinJsDce et KotlinNativeLink ont la nouvelle entrée toolOptions, qui est similaire à l'entrée kotlinOptions existante.
• Les nouvelles entrées ont l'annotation @Nested Gradle. Chaque propriété à l'intérieur des entrées a une annotation Gradle associée, telle que @Input ou @Internal.
• L'artefact de l'API du plug-in Kotlin Gradle a deux nouvelles interfaces*:
  
  • org.jetbrains.kotlin.gradle.tasks.KotlinCompilationTask, qui a l'entrée compilerOptions et la méthode compileOptions(). Toutes les tâches de compilation Kotlin implémentent cette interface.
  • org.jetbrains.kotlin.gradle.tasks.KotlinToolTask, qui a l'entrée toolOptions et la méthode toolOptions(). Toutes les tâches de l'outil Kotlin - KotlinJsDce, KotlinNativeLink et KotlinNativeLinkArtifactTask - implémentent cette interface.
    
• Certaines options du compilateur utilisent les nouveaux types au lieu du type String*:
  
  • JvmTarget
  • KotlinVersion (pour les entrées apiVersion et languageVersion)
  • JsMainFunctionExecutionModeJsMainFunctionExecutionMode
  • JsModuleKindJsModuleKind
  • JsSourceMapEmbedMode
    
    Par exemple, vous pouvez utiliser compilerOptions.jvmTarget.set(JvmTarget.JVM_11) au lieu de kotlinOptions.jvmTarget = "11".
    
    Les types kotlinOptions n'ont pas changé et ils sont convertis en interne en types compilerOptions.
    
• L'API du plug-in Kotlin Gradle est compatible en binaire avec les versions précédentes. Il existe cependant des modifications de source et de rupture d'ABI dans l'artefact kotlin-gradle-plugin. La plupart de ces modifications impliquent des paramètres génériques supplémentaires pour certains types internes. Un changement important est que la tâche KotlinNativeLink n'hérite plus de la tâche AbstractKotlinNativeCompile.
• KotlinJsCompilerOptions.outputFile et les options KotlinJsOptions.outputFile associées sont obsolètes. Utilisez plutôt l'entrée de tâche Kotlin2JsCompile.outputFileProperty.
  

Évolution des versions minimales prises en charge

À partir de Kotlin 1.8.0, la version minimale de Gradle prise en charge est 6.8.3 et la version minimale du plug-in Android Gradle prise en charge est 4.1.3.

Possibilité de désactiver la stratégie de repli du démon Kotlin

Il existe une nouvelle propriété Gradle kotlin.daemon.useFallbackStrategy, dont la valeur par défaut est true. Lorsque la valeur est false, les builds échouent en cas de problèmes de démarrage ou de communication du démon. Il existe également une nouvelle propriété useDaemonFallbackStrategy dans les tâches de compilation Kotlin, qui est prioritaire sur la propriété Gradle si vous utilisez les deux. Si la mémoire est insuffisante pour exécuter la compilation, vous pouvez voir un message à ce sujet dans les journaux.

La stratégie de repli du compilateur Kotlin consiste à exécuter une compilation en dehors du démon Kotlin si le démon échoue d'une manière ou d'une autre. Si le démon Gradle est activé, le compilateur utilise la stratégie "En cours". Si le démon Gradle est désactivé, le compilateur utilise la stratégie "Out of process".

Voir la vidéo de présentation des nouveautés de Kotlin