Discussion :

[Stéphane le calme]

Kotlin 1.4-M3 est disponible : la dernière Preview du langage apporte des modifications de la bibliothèque standard,
à l'instar de l'ajout des interfaces fonctionnelles

JetBrains a présenté la dernière étape de la preview de Kotlin 1.4 : la version 1.4-M3.

Les artefacts de la bibliothèque standard comprennent désormais des descripteurs module-info

Depuis Java 9, vous pouvez modulariser votre application grâce au projet Jigsaw. L’outil jlink vous permet de générer une image Java runtime personnalisée contenant uniquement les modules de la plateforme qui sont nécessaires pour votre application. Auparavant, il était possible d’utiliser jlink avec les artefacts de bibliothèque standard de Kotlin, mais il fallait utiliser des artefacts séparés (ceux avec le classificateur "modular") et la configuration n’était pas simple. L’impossibilité d’inclure des descripteurs de modules dans les principaux artefacts était due à des problèmes liés à l’outillage d’Android, qui sont maintenant résolus.

Kotlin 1.4 ajoute les informations du module module-info.java aux artefacts de bibliothèque standard par défaut, afin que vous puissiez les utiliser facilement avec jlink. Sous Android, veillez à utiliser le plugin Android Gradle version 3.2 ou supérieure, qui peut traiter correctement les fichiers jar avec module-info.

Interfaces fonctionnelles dans la bibliothèque standard

Le concept d'interface fonctionnelle a été introduit dans Java 8 ; il permet de définir une interface disposant d'une unique méthode abstraite, c'est-à-dire une seule méthode ne possédant pas d'implémentation par défaut.

Kotlin 1.4 prend en charge les conversions SAM pour les classes Kotlin. Vous pouvez marquer une interface ayant une seule méthode abstraite comme fun interface, puis passer un lambda comme argument lorsque cette interface est attendue comme paramètre. Dans la bibliothèque standard, les interfaces suivantes sont désormais déclarées comme fun interface :

• Comparator
• ReadOnlyProperty
• PropertyDelegateProvider (qui a été introduit dans la version 1.4-M2)

Vous pouvez utiliser un constructeur SAM qui prend un lambda comme paramètre pour créer une instance. Le code qui en résulte est bien plus simple :

Opérations de collections

• Une nouvelle fonction sumOf prend une fonction de sélecteur et renvoie une somme de ses valeurs sur tous les éléments d’une collection. Elle est assez similaire aux fonctions existantes sumBy et sumByDouble. La principale différence est que la nouvelle fonction sumOf accepte des sélecteurs avec différents types de retour, ce qui permet de traiter les sommes de différents types de la même manière. Plus précisément, sumOf produit des sommes des types Int, Long, Double, UInt, ULong. Sur la JVM, BigInteger et BigDecimal sont également disponibles.
• Les fonctions min et max ont été renommées en minOrNull et maxOrNull. Depuis leur introduction dans la version 1.0, min et max ont renvoyé null pour les collections vides. Ceci est contraire à la convention de nommage utilisée dans l’API des collections de Kotlin : les fonctions sans le suffixe *OrNull lèvent une exception si la collection réceptrice est vide. Pour obtenir un null à la place, vous devez utiliser la version *OrNull de la fonction, par exemple firstOrNull.
  JetBrains a donc décidé de modifier progressivement le comportement de min et max. Dans la version 1.4-M3, l'éditeur ajoute minOrNull et maxOrNull comme synonymes de min et max et démarre le cycle de révision pour min et max, en vue de les réintroduire avec des types de retour non null.
• JetBrains a introduit les fonctions minOf et maxOf qui renvoient la valeur minimale ou maximale de la fonction de sélecteur donnée sur les éléments de la collection. Ces fonctions apportent une solution à la situation dans laquelle il était nécessaire d’écrire map { selector }.max()!! ou maxBy { selector }!!.selector (ou min et minBy).
  
  Par souci de cohérence avec l’API existante, l'éditeur a également ajouté minOfWith et maxOfWith, qui prennent un Comparator comme argument.
  
  Les quatre nouvelles fonctions suivent la convention non-null qui est décrite ci-dessus : elles lancent des exceptions sur les collections vides et ont des versions *OrNull qui renvoient null dans ce cas.
• De nouvelles surcharges pour flatMap et flatMapTo vous permettent d’utiliser des transformations avec des types de retour ne correspondant pas au type de récepteur, à savoir :
  
  • transformations en Sequence pour Iterable, Array et Map
  • transformations en Iterable pour Sequence
• Une nouvelle fonction flatMapIndexed a été ajoutée comme contrepartie de flatMap. Comme vous le savez peut-être déjà, Indexed dans le nom d’une fonction de traitement de collection signifie que l’opération appliquée a l’index de l’élément comme paramètre.

Annotation @Throws commune

Bien que Kotlin n’ait pas d’exceptions vérifiées, il utilise l’annotation code>@Throws pour assurer l’interopérabilité avec les langages qui en ont, tels que Java et Swift. Auparavant, il y avait des annotations distinctes avec ce nom pour JVM (kotlin.jvm.Throws) et Native (kotlin.native.Throws). À partir de la version 1.4-M3, l’annotation @Throws est disponible dans la bibliothèque commune directement au sein du package kotlin (kotlin.Throws), ce qui vous permet de l’utiliser dans le code commun.

@Throws dans les fonctions de suspension pour Swift et Objective-C

Dans la version1.4-M1, l'éditeur a annoncé des changements relatifs au traitement des exceptions dans l’interop Objective-C/Swift : désormais, NSError n’est lancé que pour les exceptions qui sont des instances de classes spécifiées comme paramètres de l’annotation @Throws (ou leurs sous-classes). Dans la 1.4-M2, JetBrains a introduit une prise en charge basique des fonctions de suspension de Kotlin pour Swift et Objective-C. Avec la version 1.4-M3, il y a quelques changements dans le comportement des fonctions de suspension annotées avec @Throws :

• Si vous avez un suspend fun annoté avec @Throws, vous devez spécifier CancellationException::class comme paramètre de l’annotation @Throws. Sinon, vous obtiendrez une erreur de compilation.
• S’il n’y a pas d’annotation @Throws sur un suspend fun, il utilisera implicitement @Throws(CancellationException::class) lorsque vous l’appelez depuis Swift.

Conversion de KType en Java Type

Dans Kotlin 1.3.40, JetBrains a ajouté une fonction typeOf à la bibliothèque standard. Cette fonction renvoie une représentation d’exécution du type réifié donné T comme une instance de KType. Cependant, dans de nombreux cas d’utilisation concrets, vous devez travailler avec les objets java.lang.reflect.Type de Java reflection plutôt qu’avec KType. Il était déjà possible d’effectuer la conversion nécessaire, mais il fallait utiliser toute la dépendance kotlin-reflect. JetBrains a donc mis à jour la bibliothèque standard avec un moyen de convertir KType en Type Java – une propriété d’extension KType.javaType qui renvoie un Type Java :

Code Kotlin :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
import kotlin.reflect.javaType
import kotlin.reflect.typeOf
 
@OptIn(ExperimentalStdlibApi::class)
inline fun <reified T> accessReifiedTypeArg() {
   val kType = typeOf<T>()
   println("Kotlin type: $kType")
   println("Java type: ${kType.javaType}")
}
 
@OptIn(ExperimentalStdlibApi::class)
fun main() {
   accessReifiedTypeArg<String>()
   // Kotlin type: kotlin.String
   // Java type: class java.lang.String
 
   accessReifiedTypeArg<List<String>>()
   // Kotlin type: kotlin.collections.List<kotlin.String>
   // Java type: java.util.List<java.lang.String>
}

Notez que jusqu’à présent, le Type Java obtenu ne se comporte pas correctement dans certains cas particuliers (comme les paramètres de type annotés ou la variance declaration-site), donc KType.javaType reste expérimental.

Compatibilité

Kotlin 1.4 n’est pas rétrocompatible avec la version 1.3 dans certains cas particuliers. Tous ces cas ont été soigneusement examinés par le comité du langage et seront répertoriés dans le guide de compatibilité.

Comment essayer les dernières fonctionnalités

Comme toujours, vous pouvez essayer Kotlin en ligne sur play.kotl.in.

Dans IntelliJ IDEA et Android Studio, vous pouvez mettre à jour le plugin Kotlin vers la version 1.4-M3. Il vous suffit de :

1. Sélectionner Tools | Kotlin | Configure Kotlin Plugin Updates.
   
   
2. Dans la liste des canaux de mise à jour, sélectionnez le canal Early Access Preview X, où X est la dernière version de Kotlin.
   
   
3. Cliquez sur Vérifier à nouveau. La dernière version de build EAP apparaît.
   
   
4. Cliquez sur Installer.

Si vous souhaitez travailler sur des projets existants qui ont été créés avant d’installer la version préliminaire, vous devez configurer votre build pour la version Prewiew dans Gradle ou Maven.

Vous pouvez télécharger le compilateur de ligne de commande sur la page Github de la version 1.4-M3.

Vous pouvez utiliser les versions suivantes des bibliothèques publiées avec cette version :

• kotlinx.atomicfu version : 0.14.3-1.4-M3
• kotlinx.coroutines version : 1.3.7-1.4-M3
• kotlinx.serialization version : 0.20.0-1.4-M3
• ktor version : 1.3.2-1.4-M3

Source : JetBrains

[Stéphane le calme]

Kotlin 1.4.0-RC est disponible. Cette version permet de faire de la bibliothèque standard une dépendance par défaut
et permet d'obtenir de meilleurs rapports d'erreurs

Mise à jour du 18/08/2020 : Kotlin 1.4 est disponible et met l’accent sur la qualité et la performance

Le principal objectif de JetBrains pour cette version était d’améliorer l’expérience de développement globale avec Kotlin, notamment avec l’amélioration des performances et de la stabilité de l’EDI. Il était donc question d’optimiser autant que possible la productivité des utilisateurs de Kotlin et l'éditeur s'est concentré sur l’amélioration des points les plus importants pour les développeurs. Au total, plus de 60 problèmes de performance ont été corrigés, dont beaucoup provoquaient des blocages de l’EDI ou des fuites de mémoire. Au cours de la phase EAP de Kotlin 1.4.0, JetBrains a recueilli de nombreux retours positifs indiquant que l’expérience globale était devenue beaucoup plus agréable !

Lorsque vous travaillez avec un projet et que vous ouvrez un gros fichier Kotlin pour la première fois, son contenu avec mise en évidence de la syntaxe s’affiche maintenant beaucoup plus vite. Dans la plupart des cas, la mise en évidence syntaxique est 1,5 à 4 fois plus rapide.Le temps nécessaire à l’affichage des suggestions de saisie semi-automatique a été considérablement réduit.

Mais Kotlin 1.4 comporte également de nouvelles fonctionnalités. Par exemple, du côté de l'EDI, un nouvel Assistant de projet Kotlin flexible est proposé. Cet assistant fournit un emplacement unique pour créer et configurer des projets Kotlin de différents types, ce qui facilite le démarrage même avec des structures complexes telles que des projets multiplateformes.

Source : JetBrains

Mise à jour du 15/08/2020 : Kotlin 1.4.0 est disponible en version stable

Dans le référentiel Jetbrains dédié à Kotlin, l'éditeur a indiqué il y a quelques heures la disponibilité de la version stable. Elle s'accompagne de nouvelles fonctionnalités, notamment au niveau du compilateur, comme l'introduction de KotlinNothingValueException qui sera généré à la place de NullPointerException sur les exceptions de types Nothing [la classe Nothing représente une valeur inexistante, utilisée notamment par une fonction ne renvoyant qu'une exception (et jamais de valeur)].

Source : JetBrains

JetBrains a annoncé la disponibilité de Kotlin 1.4.0-RC, la Release Candidate de sa prochaine version majeure du langage de programmation.

Prise en charge EDI améliorée de *.gradle.kts

JetBrains a considérablement amélioré la prise en charge EDI des scripts Gradle Kotlin DSL (fichiers *.gradle.kts) dans Kotlin 1.3.70, et l'éditeur a continué sur cette lancée dans Kotlin 1.4.0-RC. Voici ce que cette nouvelle version apporte :

Chargement de la configuration du script explicitement pour de meilleures performances

Auparavant, lorsque vous ajoutiez un nouveau plugin au bloc buildscript ou plugins de votre build.gradle.kts, la nouvelle configuration de script était chargée automatiquement en arrière-plan. Ensuite, après son application, vous pouvez utiliser l'assistance de code pour le plugin nouvellement ajouté.

Pour améliorer les performances, l'éditeur a supprimé ce comportement automatique consistant à appliquer des modifications à la configuration du script lors de la saisie. À partir de Gradle 6.0 et des versions plus récentes, vous devez appliquer explicitement les modifications aux configurations en cliquant sur Charger les modifications Gradle ou en réimportant le projet Gradle.

Dans les versions antérieures de Gradle, vous devez charger manuellement la configuration du script en cliquant sur Charger la configuration dans l'éditeur.

JetBrains a ajouté une autre action dans IntelliJ IDEA 2020.1 avec Gradle 6.0+, Charger les configurations de script, qui charge les modifications des configurations de script sans mettre à jour l'ensemble du projet. Cela prend beaucoup moins de temps que de réimporter l'ensemble du projet.

Meilleurs rapports d'erreurs

Auparavant, vous ne pouviez voir les erreurs du Gradle Daemon (un processus qui s'exécute en arrière-plan et est responsable de toutes les tâches et activités liées à Gradle) que dans des fichiers journaux séparés. Désormais, à partir de Gradle 6.0 ou des versions plus récentes, Gradle Daemon renvoie directement toutes les informations sur les erreurs et les affiche dans la fenêtre de l'outil de création. Cela vous fait gagner du temps et des efforts.

Moins de boilerplate dans la configuration de votre projet

Avec les améliorations apportées au plugin Kotlin Gradle, vous pouvez écrire moins de code dans vos fichiers de construction Gradle : l'un des scénarios les plus courants est désormais activé par défaut.

Faire de la bibliothèque standard une dépendance par défaut

Une écrasante majorité de projets nécessitent la bibliothèque standard Kotlin. À partir de la version 1.4.0-RC, vous n'avez plus besoin de déclarer manuellement une dépendance sur stdlib dans chaque ensemble de sources - elle sera désormais ajoutée par défaut. La version ajoutée automatiquement de la bibliothèque standard sera la même que la version du plugin Kotlin Gradle, car ils ont le même contrôle de version.

Voici à quoi ressemblait une configuration de projet multiplateforme typique avec des cibles Android, iOS et JavaScript avant la version 1.4:

Code Kotlin :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
android()
ios()
js()
 
sourceSets {
    commonMain {
        dependencies {
            implementation("org.jetbrains.kotlin:kotlin-stdlib-common")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-common:1.3.6")
        }
    }
 
    androidMain {
        dependencies {
            implementation("org.jetbrains.kotlin:kotlin-stdlib-jdk8")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-android:1.3.6")
        }
    }
 
    jsMain {
        dependencies {
            implementation("org.jetbrains.kotlin:kotlin-stdlib-js")
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-js:1.3.6")
        }
    }
 
    iosMain {
        dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core-native:1.3.6")
        }
    }
}

Désormais, vous n'avez plus du tout besoin de déclarer explicitement une dépendance à la bibliothèque standard, et avec la prise en charge de la structure de projet hiérarchique, annoncée dans la version 1.4-M2, vous ne devez spécifier d'autres dépendances qu'une seule fois. Ainsi, votre fichier de construction Gradle deviendra beaucoup plus concis et facile à lire:

Code Kotlin :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
android()
ios()
js()
 
sourceSets {
    commonMain {
        dependencies {
            implementation("org.jetbrains.kotlinx:kotlinx-coroutines-core:1.3.6")
        }
    }
}

Pour les ensembles de sources de plateforme et les ensembles de sources partagés en backend, la bibliothèque standard correspondante sera ajoutée, tandis qu'une bibliothèque standard commune sera ajoutée au reste. Le plugin Kotlin Gradle sélectionnera la bibliothèque standard JVM appropriée en fonction du paramètre kotlinOptions.jvmTarget.

Si vous déclarez explicitement une dépendance de bibliothèque standard (par exemple, si vous avez besoin d'une version différente), le plugin Kotlin Gradle ne la remplacera pas et n'ajoutera pas une deuxième bibliothèque standard. Et si vous n'avez pas du tout besoin d'une bibliothèque standard, vous pouvez ajouter l'indicateur de désactivation aux propriétés Gradle:

Code Kotlin :

Sélectionner tout - Visualiser dans une fenêtre à part

kotlin.stdlib.default.dependency=false

Kotlin / Native

Gestion simplifiée des dépendances CocoaPods

Auparavant, une fois que vous intégriez votre projet avec le gestionnaire de dépendances CocoaPods, vous pouviez créer une partie iOS, macOS, watchOS ou tvOS de votre projet uniquement dans Xcode, distincte des autres parties de votre projet multiplateforme. Ces autres pièces pouvaient être générées dans IntelliJ IDEA.

De plus, chaque fois que vous ajoutiez une dépendance à une bibliothèque Objective-C stockée dans CocoaPods (bibliothèque Pod), vous deviez passer d'IntelliJ IDEA à Xcode, lancer la tâche pod install et y exécuter la build Xcode.

Vous pouvez désormais gérer les dépendances de pod directement dans IntelliJ IDEA tout en profitant des avantages qu'il offre pour travailler avec le code, tels que la mise en évidence et la complétion de code. Vous pouvez également créer l'ensemble du projet Kotlin avec Gradle, sans avoir à passer à Xcode. Cela signifie que vous ne devez accéder à Xcode que lorsque vous devez écrire du code Swift / Objective-C ou exécuter votre application sur un simulateur ou un appareil.

Vous pouvez désormais également travailler avec des bibliothèques de pods stockées localement.

Selon vos besoins, vous pouvez ajouter des dépendances entre:

• Un projet Kotlin et des bibliothèques de pod du référentiel CocoaPods.
• Un projet Kotlin et des bibliothèques Pod stockées localement.
• Un Kotlin Pod (projet Kotlin utilisé comme dépendance CocoaPods) et un projet Xcode avec une ou plusieurs cibles.

Terminez la configuration initiale et lorsque vous ajoutez une nouvelle dépendance à CocoaPods, réimportez simplement le projet dans IntelliJ IDEA. La nouvelle dépendance sera ajoutée automatiquement. Aucune étape supplémentaire n'est requise.

Générer des fichiers .dSYM sur les cibles Apple par défaut

Le débogage d'un plantage d'application iOS implique parfois l'analyse des rapports d'incident, et les rapports d'incident nécessitent généralement une symbolisation pour devenir correctement lisibles. Pour symboliser les adresses dans Kotlin, le bundle .dSYM pour le code Kotlin est requis. À partir de la version 1.4-M3, le compilateur Kotlin / Native produit par défaut des .dSYM pour les binaires de version sur les plateformes Darwin. Cela peut être désactivé avec l'indicateur -Xadd-light-debug = disable du compilateur. Sur les autres plateformes, cette option est désactivée par défaut. Pour basculer cette option dans Gradle, utilisez:

Code Kotlin :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
kotlin {
    targets.withType<org.jetbrains.kotlin.gradle.plugin.mpp.KotlinNativeTarget> {
        binaries.all {
            freeCompilerArgs += "-Xadd-light-debug={enable|disable}"
        }
    }
}

Kotlin 1.4.0-RC est également livré avec de nouvelles fonctionnalités pour déboguer les coroutines et définir des fonctions récursives profondes

Source : JetBrains