Kotlin 1.4-M1 est disponible avec un nouvel algorithme d'inférence de type plus puissant
Kotlin 1.4-M1 est disponible, une version préliminaire avec un nouvel algorithme d'inférence de type plus puissant
et un nouveau backend pour Kotlin/JS qui apporte des améliorations majeures aux artefacts
En décembre 2019, au cours de son discours-programme à la conférence de Kotlin, Andrey Breslav, concepteur principal de Kotlin, a parlé de la vision stratégique de Kotlin 1.4. « Notre vision est que Kotlin soit un compagnon fiable pour tous vos efforts, un choix par défaut pour vos tâches. Pour ce faire, nous allons le faire briller sur toutes les plateformes. De multiples études de cas d'entreprises bien connues dans l'industrie montrent que nous progressons bien dans cette direction », a-t-il déclaré.
La première version préliminaire de cette nouvelle version majeure, la 1.4-M1, du langage est disponible, un aperçu dans lequel il est déjà possible essayer certaines des nouvelles choses proposées par JetBrains. En gros, en ce qui concerne les nouvelles fonctionnalités, on a :
- un nouvel algorithme d'inférence de type plus puissant, selon JetBrains, est activé par défaut ;
- les contrats sont désormais disponibles pour les fonctions finales des membres ;
- le compilateur Kotlin / JVM génère désormais des annotations de type dans le bytecode pour les cibles Java 8+ ;
- il y a un nouveau backend pour Kotlin / JS qui apporte des améliorations majeures aux artefacts résultants ;
- changements évolutifs dans la bibliothèque standard : achèvement des cycles de dépréciation et dépréciation de certaines parties supplémentaires.
Le nouvel algorithme d'inférence de type
Kotlin 1.4 utilise un nouvel algorithme d'inférence de type annoncé comme étant plus puissant. Il était possible de l'essayer avec Kotlin 1.3 en spécifiant une option de compilation, et maintenant il est utilisé par défaut dans la nouvelle version. Ce nouvel algorithme apporte quelques améliorations notamment la conversion SAM qui vous permet de passer un lambda lorsqu'une interface avec une « méthode abstraite unique » est attendue. Avant, vous ne pouviez appliquer la conversion SAM que lorsque vous travailliez avec des méthodes Java et des interfaces Java de Kotlin, et maintenant vous pouvez également l'utiliser avec des fonctions et des interfaces Kotlin.
Kotlin prend désormais en charge la conversion SAM pour les interfaces Kotlin. Notez qu'il fonctionne différemment qu'en Java : vous devez marquer explicitement les interfaces fonctionnelles. Après avoir marqué une interface avec le mot clé fun, vous pouvez à la place passer un lambda comme argument chaque fois qu'une telle interface est attendue comme paramètre :
Code:
1
2
3
4
5
6
7
8
9
10
11
| fun interface Action {
fun run()
}
fun runAction(a: Action) = a.run()
fun main() {
runAction {
println("Hello, Kotlin 1.4!")
}
} |
Le nouvel algorithme d'inférence déduit des types dans de nombreux cas où l'ancienne inférence vous obligeait à les spécifier explicitement. Par exemple, dans l'exemple suivant, le type du paramètre lambda it infère correctement à String? :
Code:
1
2
3
4
5
| val rulesMap: Map<String, (String?) -> Boolean> = mapOf(
"weak" to { it != null },
"medium" to { !it.isNullOrBlank() },
"strong" to { it != null && "^[a-zA-Z0-9]+$".toRegex().matches(it) }
) |
Support aux contrats
JetBrains annonce que la syntaxe pour définir les contrats personnalisés reste expérimentale, mais prend en charge quelques nouveaux cas où les contrats pourraient être utiles. Vous pouvez désormais utiliser des paramètres de type générique réifiés pour définir un contrat. Par exemple, vous pouvez implémenter le contrat suivant pour la assertIsInstancefonction :
Code:
1
2
3
4
5
6
7
8
9
|
inline fun <reified T> assertIsInstance(value: Any?) {
contract {
returns() implies (value is T)
}
assertTrue(value is T)
}
} |
Le paramètre de type T étant réifié, vous pouvez vérifier son type dans le corps de la fonction. Cela est désormais également possible à l'intérieur du contrat. Une fonction similaire avec le message d'assertion sera ajoutée à la kotlin.testbibliotheque ultérieurement, annonce JetBrains. De plus, vous pouvez désormais définir des contrats personnalisés pour les membres final. Auparavant, la définition de contrats pour les fonctions membres était totalement interdite car la définition de contrats sur certains des membres de la hiérarchie implique une hiérarchie des contrats correspondants, et cela reste une question de conception et de discussion. Cependant, si une fonction membre est final et ne remplace aucune autre fonction, il est sûr de définir un contrat pour elle.
Kotlin/JVM
Depuis la version 1.3.70, Kotlin a pu générer des annotations de type dans le bytecode JVM afin qu'elles deviennent disponibles au moment de l'exécution. Cette fonctionnalité a été demandée par la communauté depuis un certain temps car elle facilite l'utilisation de certaines bibliothèques Java existantes et donne plus de pouvoir aux développeurs de nouvelles bibliothèques.
Kotlin/JS
Pour Kotlin/JS, ce jalon comprend quelques modifications du Gradle DSL, et c'est la première version à inclure le nouveau backend du compilateur IR, qui permet des optimisations et de nouvelles fonctionnalités.
Modifications apportées à Gradle DSL
Dans les plugins kotlin.js et Gradle multiplatform, un nouveau paramètre important a été introduit. À l'intérieur du bloc cible de votre build.gradle.ktsfichier, le paramètre produceExecutable() est désormais disponible et requis si vous souhaitez générer des artefacts .js pendant votre build.
Code:
1
2
3
4
5
6
7
8
9
| kotlin {
target {
useCommonJs()
produceExecutable()
browser {}
}
} |
Vous pouvez omettre produceExecutable() si vous écrivez une bibliothèque Kotlin/JS. Lorsque vous utilisez le nouveau backend du compilateur IR, l'omission de ce paramètre signifie qu'aucun fichier JS exécutable ne sera généré (et, en tant que tel, le processus de génération s'exécutera plus rapidement). Un klibfichier est généré dans le build/libsdossier qui peut être utilisé à partir d'autres projets Kotlin/JS, ou comme dépendance dans le même projet. Si vous ne spécifiez pas produceExecutable() explicitement, ce comportement se produit par défaut.
Nouveau backend
Kotlin 1.4-M1 est la première version à inclure le nouveau backend du compilateur IR pour la cible Kotlin/JS. Ce backend est le fondement d'optimisations considérablement améliorées et le facteur déterminant pour certains changements dans la façon dont Kotlin/JS interagit avec JavaScript et TypeScript. Bien qu'il ne soit pas encore activé par défaut, JetBrains encourage les développeurs à l'essayer avec leurs projets, à commencer à préparer leurs bibliothèques pour le nouveau backend, et bien sûr à faire part des commentaires et à enregistrer les problèmes au fur et à mesure.
Pas de compatibilité binaire
Un changement majeur avec le nouveau backend du compilateur IR est l'absence de compatibilité binaire avec le backend par défaut. Un manque d'une telle compatibilité entre les deux backends pour Kotlin/JS signifie qu'une bibliothèque créée avec le nouveau backend du compilateur IR ne peut pas être utilisée à partir du backend par défaut, et vice versa.
Si vous souhaitez utiliser le backend du compilateur IR pour votre projet, vous devez mettre à jour toutes les dépendances de Kotlin vers des versions qui prennent en charge ce nouveau backend. Les bibliothèques publiées par JetBrains pour Kotlin 1.4-M1 ciblant Kotlin/JS contiennent déjà tous les artefacts requis pour une utilisation avec le nouveau backend du compilateur IR. Lorsque vous dépendez d'une telle bibliothèque, les artefacts corrects sont automatiquement sélectionnés par Gradle (c'est-à-dire qu'il n'est pas nécessaire de spécifier une coordonnée spécifique à l'IR). Veuillez noter que certaines bibliothèques, telles que kotlin-wrappers, ont des problèmes avec le nouveau backend du compilateur IR car elles reposent sur des caractéristiques spécifiques du backend par défaut.
DCE optimisé
Le nouveau backend du compilateur IR est capable de faire des optimisations beaucoup plus agressives par rapport au backend par défaut. Le code généré fonctionne mieux avec les analyseurs statiques, et il est même possible d'exécuter le code généré à partir du nouveau backend du compilateur IR via le Closure Compiler de Google et d'utiliser ses optimisations en mode avancé. Le changement le plus visible ici concerne la taille du code des artefacts générés. Une méthode améliorée d'élimination du code mort permet aux artefacts de se réduire considérablement.
Source : Kotlin 1.4-M1
Et vous ?
:fleche: Que pensez-vous des améliorations apportées au langage Kotlin ?
Voir aussi
:fleche: À quoi s'attendre dans Kotlin 1.4 qui sera publié l'année prochaine ? Le langage promet d'être encore plus rapide, performant et multiplateforme
:fleche: Kotlin 1.3.60 est disponible ! Cette version s'accompagne d'améliorations d'outils pour le débogage et apporte une préversion de certaines fonctionnalités déjà implémentées de Kotlin 1.4
:fleche: Ouverture de la rubrique dédiée à Kotlin avec les meilleurs tutoriels et cours de formation gratuits
:fleche: Entre Java et Kotlin, lequel de ces langages est le meilleur pour le développement d'applications Android ?
:fleche: Android : Kotlin est désormais le langage préféré et recommandé par Google. Vers la fin de Java pour le développement Android ?
