JetBrains a annoncé la disponibilité de Kotlin 1.3.60, le langage de programmation orienté objet et fonctionnel, avec un typage statique qui permet de compiler pour la machine virtuelle Java, JavaScript, et vers plusieurs plateformes en natif (grâce à LLVM). En plus des améliorations de qualité, cette version met l'accent sur:
- l'optimisation de la comparaison des classes inline ;
- les améliorations des outils pour le débogage, le convertisseur J2K et les scripts Gradle écrits en Kotlin ;
- la prise en charge de plusieurs plateformes / cibles Kotlin / natives ;
- l'amélioration de l'expérience de Kotlin / MPP EDI ;
- préversion de certaines fonctionnalités déjà implémentées de Kotlin 1.4.
Changements dans le langage
Améliorations pour les classes inline
La comparaison d'égalité de deux instances de classes inline a entraîné une mise en boîte inutile de leurs valeurs sous-jacentes. À partir de la version 1.3.60, les comparaisons de valeurs sont optimisées :
| Code Kotlin : | Sélectionner tout |
1 2 3 4 5 6 7 8 9 10 11 12 13 | inline class MyClass(val value: Int) { // Generated by the compiler: // public static final boolean equals-impl0(int p1, int p2) { // return p1 == p2; // } } fun main() { val first = MyClass(1) val second = MyClass(1) println(first == second) // Called under the hood: // MyClass.equals-impl0(first, second) } |
Dans cet extrait de code, une méthode statique spéciale equals-impl0, qui compare les valeurs sous-jacentes, est générée pour chaque classe inline. Lorsque vous utilisez la comparaison d’égalité sur des occurrences, elle est appelée sous le capot.
Pour le moment, il n’est pas possible de remplacer equals / hashCode pour les classes inline. La méthode equals-impl0 générée compare simplement les valeurs. Dans les futures versions, lorsque l'équivalent personnalisé pour les classes inline est pris en charge, la même méthode equals-imp0 doit être utilisée sous le capot.
Notez que pour des raisons de compatibilité, cette optimisation fonctionnera pour la classe kotlin.Result à partir de Kotlin 1.4 uniquement.
Messages d'erreur améliorés
Dans de rares cas, lorsque vous lisez un message d'erreur du compilateur, la raison pour laquelle l'erreur se produit n'est pas évidente. L'équipe essaye de résoudre ce problème et d’améliorer les messages d’erreur susceptibles de semer la confusion.
Kotlin soutient la convention de fin de lambda : le lambda peut être retiré des parenthèses. Un tel lambda peut également commencer à la ligne suivante. Cette convention est source de confusion parfois lorsque le compilateur suppose que les accolades de la ligne suivante doivent être l’argument lambda de la fonction, mais que ce n’est pas le cas :
Maintenant, le message d'erreur pour de tels cas a été amélioré et vous pouvez appliquer automatiquement une solution simple : insérez un point-virgule à la fin de la ligne précédente.
Un autre cas à souligner est la tentative de rendre lazy une variable mutable. De par sa conception, une variable lazy est en lecture seule, mais cela peut être source de confusion. Maintenant, le message d'erreur est amélioré et un correctif rapide automatique est disponible:
Prise en charge d'IntelliJ IDEA
Scratch et feuilles de calcul
L'équipe a amélioré les fichiers Scratch, qui vous permettent de réaliser de petites expériences avec votre code. Il est maintenant plus facile de voir les résultats, qui sont affichés dans une fenêtre différente. La sortie multiligne est encapsulée et la sortie de la ligne donnée est mise en surbrillance:
Parfois, cependant, les fichiers Scratch ne sont pas bien lus. Dans certains cas, vous préféreriez utiliser un bac à sable faisant partie du projet plutôt qu'un bac à sable défini en dehors du projet. Cela peut être particulièrement utile à des fins pédagogiques, lors de la création de projets de démonstration ou lors de présentations. Pour tous ces cas d'utilisation interviennent les toutes nouvelles feuilles de calcul Kotlin :
Les feuilles de calcul Kotlin ressemblent beaucoup aux fichiers Scratch sur les plans conceptuel et technique : vous pouvez jouer avec votre base de code et voir les résultats immédiatement. La principale différence entre les deux est que les feuilles de calcul font partie du projet, ce qui signifie qu'elles peuvent être stockées dans un VCS et partagées, tandis que les fichiers Scratch sont destinés à être utilisés en dehors d'un projet.
build.gradle.kts
L'équipe travaille à l’amélioration de l'expérience utilisateur avec les scripts de construction de Kotlin Gradle. Elle a déjà terminé et mis en évidence les améliorations de performances et va continuer à travailler en étroite collaboration avec Gradle pour l’améliorer.
Amélioration du débogage
Vous pouvez maintenant définir des points d'arrêt de fonction dans le code Kotlin. Le débogueur arrêtera alors l'exécution en entrant ou sortant de la fonction correspondante. Vous pouvez également définir une condition d'entrée supplémentaire si nécessaire:
Complétion et amélioration des importations
Plusieurs bogues connus ont été corrigés, comme la complétion pour les cas où le nom du paquet correspond au nom de la variable locale.
Maintenant, si vous définissez un typealias pour enum, ses membres sont maintenant correctement affichés:
Nouveau convertisseur Java-Kotlin
L'équipe a fait du bon travail sur le nouveau convertisseur Java vers Kotlin. De nombreux problèmes ont été résolus, tels que la conversion pour les importations statiques et l'analyse appropriée des utilisations d'une collection, si une collection devenait mutable ou en lecture seule après la conversion, même si cette collection elle-même était un argument générique.
Désormais, lorsque vous convertissez plusieurs fichiers à la fois, ils sont analysés ensemble et les utilisations des autres fichiers affectent le résultat final. Par exemple, si vous passez null en tant qu'argument String à une fonction foo en Java, après avoir converti une fonction et son utilisation ensemble, la fonction Kotlin convertie prendra une chaîne nullable comme argument:
Source : note de version