JetBrains a annoncé la disponibilité de Kotlin 1.4.20. Voici quelques points forts de cette mise à jour :- Prise en charge de nouvelles fonctionnalités JVM, telles que la concaténation de chaînes via invokedynamic.
- Amélioration des performances et gestion des exceptions pour les projets KMM.
- Extensions pour JDK Path: Path("dir") / "file.txt".
L'éditeur propose également de nombreux correctifs et améliorations pour les fonctionnalités existantes, y compris celles ajoutées dans la version 1.4.0. Par conséquent, si vous avez rencontré des problèmes avec l’une de ces fonctionnalités, le moment est venu de les réessayer.
Kotlin / JVM
Sur la JVM, JetBrains a ajouté la nouvelle cible JVM 15 et s'est principalement concentré sur l'amélioration des fonctionnalités et des performances existantes, ainsi que sur la correction des bogues.
Concaténation de chaînes dynamique
Depuis Java 9, la concaténation de chaînes sur la JVM a été effectuée via l'appel de méthode dynamique (l'instruction invokedynamic dans le bytecode). Cela fonctionne plus rapidement et consomme moins de mémoire que l'implémentation précédente, et cela laisse de la place pour les optimisations futures sans nécessiter de changements de bytecode.
JetBrains a commencé à implémenter ce mécanisme dans Kotlin pour de meilleures performances, et il peut désormais compiler des concaténations de chaînes en appels dynamiques sur des cibles JVM 9+.
Actuellement, cette fonctionnalité est expérimentale et couvre les cas suivants:
- String.plus dans les formes opérateur (a + b), explicite (a.plus (b)) et référence ((a :: plus) (b)).
- toString sur les classes inline et data.
- Les string templates, sauf pour ceux avec un seul argument non constant
Pour activer la concaténation de chaîne de caractères invokedynamic, ajoutée à l'option du compilateur -Xstring-concat l'une des valeurs suivantes :
- indy-with-constants pour effectuer des concaténations de chaînes de caractères invokedynamic avec StringConcatFactory.makeConcatWithConstants() (il est prévu que ce soit l'option par défaut pour les cibles JVM 9+ dans la version 1.5).
- indy pour effectuer des concaténations de chaînes de caractères invokedynamic avec StringConcatFactory.makeConcat()..
- inline pour repasser à la concaténation classique par StringBuilder.append().
Désactivation des espaces de travail granulaires (expérimental)
Pour accélérer les temps de build, le plugin Kotlin/JS Gradle installe uniquement les dépendances requises pour une tâche Gradle particulière. Par exemple, le package webpack-dev-server n’est installé que lorsque vous exécutez l’une des tâches *Run et non lorsque vous exécutez la tâche assemble. Bien que cela permette d’éviter des téléchargements inutiles, des problèmes peuvent survenir lors de l’exécution de plusieurs processus Gradle en parallèle. Lorsque les exigences de dépendance ne coïncident pas, les deux installations de package npm peuvent causer des erreurs.
Pour résoudre ce problème, Kotlin 1.4.20 inclut une nouvelle option (expérimentale) permettant de désactiver ce que l’on appelle les espaces de travail granulaires. À l’instar de la prise en charge expérimentale des résolutions de dépendances sélectives, cette fonctionnalité est actuellement accessible via YarnRootExtension, mais elle sera probablement intégrée plus étroitement avec le reste du DSL Kotlin/JS Gradle. Pour l’utiliser, ajoutez le snippet suivant à votre fichier build.gradle.kts :
| Code Kotlin : | Sélectionner tout |
rootProject.plugins.withType(YarnPlugin::class.java) { rootProject.the<YarnRootExtension>().disableGranularWorkspaces() }
Avec cette configuration, le plugin Kotlin/JS Gradle installera toutes les dépendances npm pouvant être utilisées par votre projet, y compris celles utilisées par les tâches qui ne sont pas en cours d’exécution. Cela signifie que la première build de Gradle peut prendre un peu plus de temps, mais que les dépendances téléchargées seront à jour pour toutes les tâches que vous exécuterez. De cette façon, vous pouvez éviter les conflits lors de l’exécution en parallèle de plusieurs processus Gradle.
Kotlin / JS
Kotlin / JS continue d'évoluer à un rythme rapide, et cette version apporte une variété d'améliorations, y compris de nouveaux templates pour son assistant de projet, une DSL améliorée pour un meilleur contrôle de la configuration du projet, et plus encore. Le nouveau compilateur IR a également reçu une toute nouvelle façon de compiler des projets en ignorant les erreurs dans leur code.
Modifications de Gradle DSL
Le DSL Kotlin / JS Gradle a reçu un certain nombre de mises à jour qui simplifient la configuration et la personnalisation du projet, notamment des ajustements de configuration du webpack, des modifications du fichier package.json généré automatiquement et un contrôle amélioré des dépendances transitives.
Point unique pour la configuration du Webpack
Kotlin 1.4.20 introduit un nouveau bloc de configuration pour la cible browser appelé commonWebpackConfig. À l'intérieur, vous pouvez ajuster les paramètres communs à partir d'un seul point, au lieu de dupliquer les configurations pour webpackTask, runTask et testTask.
Pour activer la prise en charge CSS par défaut pour les trois tâches, il vous suffit d'inclure l'extrait suivant dans le build.gradle(.kts) de votre projet:
| Code Kotlin : | Sélectionner tout |
1 2 3 4 5 6 7 8 | kotlin { browser { commonWebpackConfig { cssSupport.enabled = true } binaries.executable() } } |
Personnalisation package.json à partir de Gradle
Le fichier package.json définit généralement le comportement d'un projet JavaScript, identifie les scripts disponibles à exécuter, les dépendances, etc. Il est automatiquement généré pour les projets Kotlin / JS pendant les temps de build. Étant donné que le contenu de package.json varie d'un cas à l'autre, JetBrains a reçu de nombreuses demandes pour proposer aux développeurs un moyen simple de personnaliser ce fichier.
Dès la version Kotlin 1.4.20, vous pouvez ajouter des entrées au fichier de projet package.json à partir du script de construction Gradle. Pour ajouter des champs personnalisés à votre package.json, utilisez la fonction customField dans le bloc packageJson des compilations:
| Code Kotlin : | Sélectionner tout |
1 2 3 4 5 6 7 | kotlin { js(BOTH) { compilations["main"].packageJson { customField("hello", mapOf("one" to 1, "two" to 2)) } } } |
Lorsque vous construisez le projet, cela ajoutera le bloc suivant au fichier de configuration build/js/packages/projectName/package.json :
Envoyé par sortie"hello": {
"one": 1,
"two": 2
}
"one": 1,
"two": 2
}
Résolutions sélectives de dépendance de fil (expérimental)
Lorsque vous incluez des dépendances npm, vous souhaitez parfois avoir un contrôle précis sur leurs dépendances (dépendances transitives). Il existe de nombreuses raisons pour lesquelles cela pourrait être le cas. Vous souhaiterez peut-être appliquer une mise à niveau importante à l'une des dépendances d'une bibliothèque que vous utilisez. Ou vous pouvez restaurer une mise à jour d'une dépendance transitive qui provoque actuellement un plantage de votre application. Les résolutions de dépendances sélectives de Yarn vous permettent de remplacer les dépendances spécifiées par l'auteur d'origine, afin que vous puissiez continuer à développer.
Avec Kotlin 1.4.20, JetBrains propose un moyen préliminaire (expérimental) de configurer cette fonctionnalité à partir du script de construction Gradle d'un projet. Alors que JetBrains travaille toujours sur une intégration API fluide avec le reste des options Kotlin / JS, vous pouvez déjà utiliser la fonctionnalité via YarnRootExtension dans YarnPlugin. Pour affecter la version résolue d'un package pour votre projet, utilisez la fonction de resolution. Dans ses arguments, spécifiez le sélecteur de nom de package (tel que spécifié par Yarn) et la version souhaitée.
Un exemple de configuration pour la résolution sélective des dépendances dans votre fichier build.gradle.kts ressemblerait à ceci:
| Code Kotlin : | Sélectionner tout |
1 2 3 4 5 6 | rootProject.plugins.withType<YarnPlugin> { rootProject.the<YarnRootExtension>().apply { resolution("react", "16.0.0") resolution("processor/decamelize", "3.0.0") } } |
Ici, toutes vos dépendances npm qui nécessitent react recevront la version 16.0.0, et le processeur recevra sa dépendance decamelize en tant que version 3.0.0. En outre, vous pouvez également transmettre les appels d'inclusion et d'exclusion au bloc de résolution, ce qui vous permet de spécifier des contraintes sur les versions acceptables.
Nouveaux templates pour l'assistant de projet pour Kotlin
Pour vous offrir des moyens plus pratiques de personnaliser votre projet lors de la création, l'assistant de projet pour Kotlin est fourni avec de nouveaux templates ajustables pour les applications Kotlin / JS. Il existe des templates pour le navigateur et les environnements d'exécution Node.js. Ils constituent un bon point de départ pour votre projet et permettent d'affiner la configuration initiale. Cela inclut des paramètres tels que l'activation du nouveau compilateur IR ou la configuration de la prise en charge de bibliothèques supplémentaires.
Avec Kotlin 1.4.20, trois modèles sont disponibles:
- Browser Application : vous permet de configurer un projet Kotlin / JS Gradle de base qui s'exécute dans le navigateur.
- React Application : qui contient tout ce dont vous avez besoin pour commencer à créer une application React en utilisant les kottlin-wrappers appropriés. Il fournit des options pour activer les intégrations pour les feuilles de style, les composants de navigation et les conteneurs d'état.
- Node.js Application: préconfigure votre projet pour qu'il s'exécute dans un environnement d'exécution Node.js. Il est livré avec l'option d'inclure directement le package expérimental kotlinx-nodejs.
Ignorer les erreurs de compilation (expérimental)
Avec Kotlin 1.4.20, JetBrains a également présenté une toute nouvelle fonctionnalité disponible dans le compilateur IR Kotlin/JS : ignoring compilation errors. Cette fonctionnalité vous permet d’essayer votre application même si elle est dans un état où elle ne se compilerait pas normalement. Par exemple, quand vous effectuez une refactorisation complexe ou travaillez sur une partie du système qui n’est absolument pas liée à une erreur de compilation. Avec ce nouveau mode de compilation, le compilateur ignore tout code erroné et le remplace par des exceptions d’exécution au lieu de refuser de compiler.
Kotlin 1.4.20 propose deux principes de tolérance pour ignorer les erreurs de compilation dans votre code :
- En mode SEMANTIC, le compilateur acceptera du code qui est correct du point de vue de la syntaxe, mais qui n’a pas de sens sémantiquement parlant. Un exemple de cela serait une instruction contenant une incompatibilité de type (comme val x: String = 3).
- En mode SYNTAX, le compilateur acceptera absolument n’importe quel code, même s’il contient des erreurs de syntaxe. Indépendamment de ce que vous écrivez, le compilateur essaiera toujours de générer un exécutable fonctionnel.
Comme il s’agit d’une fonctionnalité expérimentale, ignorer les erreurs de compilation requiert un opt-in via une option du compilateur. Elle n’est disponible que pour le compilateur IR Kotlin/JS. Pour l’activer, ajoutez le snippet suivant à votre fichier build.gradle.kts :
| Code Kotlin : | Sélectionner tout |
kotlin { js(IR) { compilations.all { compileKotlinTask.kotlinOptions.freeCompilerArgs += listOf("-Xerror-tolerance-policy=SYNTAX") } } }
Kotlin/Native
La performance reste l’une des principales priorités de Kotlin/Native dans la version 1.4.20. Parmi les fonctionnalités essentielles à cet égard figure le prototype du nouveau mécanisme d’analyse d’échappement, que JetBrains prévoit de peaufiner et d’améliorer dans les prochaines versions. JetBrains a également apporté d’autres améliorations de la performance, avec les vérifications de plages plus rapides notamment (in).
Autre aspect des améliorations apportées au développement Kotlin/Native dans la version 1.4.20 : la correction de bogues. JetBrains a résolu un certain nombre de problèmes, y compris ceux trouvés dans les nouvelles fonctionnalités de la version 1.4, comme le mécanisme de partage de code. Un ensemble d’améliorations corrige les incohérences de comportement entre Kotlin/Native et Kotlin/JVM dans des cas particuliers, tels que l’initialisation de propriété ou l’application d’equals et de hashCode à des références fonctionnelles.
Enfin, JetBrains a étendu les capacités d’interopérabilité avec Objective-C grâce à une option permettant d’encapsuler les exceptions Objective-C dans des exceptions Kotlin afin de les gérer dans le code Kotlin.
Analyse d’échappement
L’analyse d’échappement est une technique utilisée par le compilateur pour décider si un objet peut être alloué sur la pile ou doit « s’échapper » vers le tas. L’allocation sur la pile est beaucoup plus rapide et ne nécessite pas de passage ultérieur du récupérateur de mémoire.
Bien que Kotlin/Native dispose déjà d’une analyse d’échappement locale, JetBrains a ajouté un prototype d’implémentation d’une nouvelle analyse d’échappement globale plus efficace. Cette configuration s’effectue dans une phase de compilation séparée pour les builds de version finale (avec l’option de compilateur -opt).
Selon JetBrains, ce prototype a déjà donné des résultats prometteurs et l'éditeur a notamment constaté une augmentation moyenne des performances de 10%. JetBrains cherche également des moyens d’optimiser l’algorithme afin qu’il trouve davantage d’objets pour l’allocation de pile et accélère encore plus le programme.
Si vous souhaitez désactiver la phase d’analyse d’échappement, utilisez l’option du compilateur -Xdisable-phases=EscapeAnalysis.
Source : JetBrains