Kotlin 1.4-M3 est disponible : modifications de la bibliothèque standard

Delphine Massenhove

Read this post in other languages:

• English
,
• 日本語
,
• 한국어

Kotlin 1.4-M3 est disponible : modifications de la bibliothèque standard

Nous avons le plaisir de vous présenter la dernière étape de la preview de Kotlin 1.4 : la version 1.4-M3. Dans cet article, nous vous guidons à travers les diverses modifications que cette preview apporte à la bibliothèque standard de Kotlin. D’autres composants font également l’objet de mises à jour dans la version M3, mais nous les aborderons dans un prochain article sur la version release candidate (1.4-RC).

Les modifications de la bibliothèque standard dans la version 1.4-M3 portent sur les points suivants :

• Les bibliothèques JVM incluent maintenant le descripteur module-info
• Les interfaces fonctionnelles sont ajoutés à la bibliothèque standard
• De nouvelles opérations de collections pour couvrir des cas concrets
• L’annotation @Throws dans la bibliothèque commune
• L’abandon de certaines fonctions sur les tableaux de valeurs en virgule flottante

Vous trouverez la liste complète des modifications dans le journal des modifications. Comme toujours, nous sommes extrêmement reconnaissants envers nos contributeurs externes.

Nous comptons sur vous pour essayer la preview et nous faire part de vos retours.

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.

fun interfaces dans la bibliothèque standard

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.

  data class OrderItem(val name: String, val price: Double, val count: Int)
  
  fun main() {
  //sampleStart
      val order = listOf<OrderItem>(
          OrderItem("Cake", price = 10.0, count = 1),
  	OrderItem("Coffee", price = 2.5, count = 3),
          OrderItem("Tea", price = 1.5, count = 2))
      
      val total = order.sumOf { it.price * it.count} // Double
      val count = order.sumOf { it.count } // Int
  //sampleEnd
      println("You've ordered $count items that cost $total in total")
  }
  

• 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.
  Nous avons donc décidé de modifier progressivement le comportement de min et max. Dans la version 1.4-M3, nous ajoutons minOrNull et maxOrNull comme synonymes de min et max et nous démarrons le cycle de révision pour min et max, en vue de les réintroduire avec des types de retour non null.
• Nous avons 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).

  data class OrderItem(val name: String, val price: Double, val count: Int)
  
  fun main() {
  //sampleStart
      val order = listOf<OrderItem>(
          OrderItem("Cake", price = 10.0, count = 1),
          OrderItem("Coffee", price = 2.5, count = 3),
          OrderItem("Tea", price = 1.5, count = 2))
      
      val highestPrice = order.maxOf { it.price }
  //sampleEnd    
      println("The most expensive item in the order costs $highestPrice")
  }
  

  Par souci de cohérence avec l’API existante, nous avons également ajouté minOfWith et maxOfWith, qui prennent un Comparator comme argument.
  Les quatre nouvelles fonctions suivent la convention non-null que nous avons 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

  fun main() {
  //sampleStart
      val list = listOf("kot", "lin")
      val lettersList = list.flatMap { it.asSequence() }
      val lettersSeq = list.asSequence().flatMap { it.toList() }
  //sampleEnd    
      println(lettersList)
      println(lettersSeq.toList())
  }
  

• 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.

  fun main() {
  //sampleStart
      val list = listOf("hello", "kot", "lin", "world")
      val kotlin = list.flatMapIndexed { index, item ->
          if (index in 1..2) item.toList() else emptyList() 
      }
  //sampleEnd
      println(kotlin)
  }
  

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, nous avions 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, nous avons 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’appellez depuis Swift.

Égalité dans les tableaux de valeurs à virgule flottante

Beaucoup d’entre vous connaissent ces fonctions d’extension pratiques pour les types de conteneurs : contains, indexOf, et lastIndexOf. Il y a quelque temps, nous avons découvert que leur comportement sur les tableaux à virgule flottante (FloatArray et DoubleArray) peut être discutable et sembler incorrect.
En effet, ils utilisent la norme IEEE 754 pour l’arithmétique en virgule flottante. Cette norme définit les règles d’égalité suivantes pour les cas particuliers :

• NaN n’est pas égal à NaN
• -0.0 est égal à 0.0

Ces règles peuvent entraîner des résultats inattendus, par exemple :

fun main() {
//sampleStart
    val darray = doubleArrayOf(Double.NaN, 0.0)
    println (darray.contains(darray[0])) // false!
//sampleEnd
}

De plus, un tel comportement n’est pas cohérent avec la façon dont ces mêmes fonctions opèrent sur les listes, car elles utilisent l’égalité ordre total :

fun main() {
//sampleStart
    val listOfDouble: List<Double> = listOf(0.0, Double.NaN)
    val listFromArray: List<Double> = doubleArrayOf(0.0, Double.NaN).asList()

    println(listOfDouble.contains(Double.NaN))  // true
    println(listFromArray.contains(Double.NaN))  // false dans les versions précédentes
//sampleEnd
}

Dans la version 1.4-M3, nous commençons le cycle de révision des fonctions d’extension contains, indexOf et lastIndexOf de FloatArray et DoubleArray. Lorsque vous essayerez de les utiliser, vous verrez des avertissements avec des instructions pour le remplacement des utilisations de ces fonctions.
Dans les prochaines versions, nous allons relever le niveau de dépréciation à ERROR et supprimer ces fonctions de l’API publique.

Conversion de KType en Java Type

Dans Kotlin 1.3.40, nous avons 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. Nous avons maintenant 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 :

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. Vous pouvez trouver plus de détails sur les cas non pris en charge dans ce ticket.

Compatibilité

Notez que 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é" (similaire à celui-ci). Pour le moment, vous pouvez trouver cette liste dans YouTrack.

Notes de pré-version

Notez que les garanties de rétrocompatibilité ne concernent pas les versions préliminaires. Les fonctionnalités et l’API peuvent changer dans les versions ultérieures. Lorsque nous arriverons au release candidate final, tous les binaires produits par les versions préliminaires seront interdits par le compilateur et vous devrez recompiler tout ce qui a été compilé par la version 1.4 ‑ Mx.

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. Voir comment procéder.

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

Les détails de la version et la liste des bibliothèques compatibles sont également disponibles ici.

Partager votre avis

Nous vous remercions pour tous vos rapports de bugs dans notre outil de suivi et ferons de notre mieux pour corriger tous les problèmes les plus importants avant la version finale.

Nous vous invitons à rejoindre le canal #eap sur notre Slack Kotlin (demandez une invitation ici). Sur ce canal, vous pouvez poser vos questions, participer aux discussions et recevoir es notifications sur les nouveaux builds.

Faison évoluer Kotlin ensemble !

Contributions externes

Nous remercions tous nos contributeurs externes dont les requêtes pull ont été incluses dans cette version :

• Toshiaki Kameyama
• Steven Schäfer
• Jinseong Jeon
• pyos
• Mark Punzalan
• rapturemain
• Vitaly Tihonov
• Mads Ager
• Subroh Nishikori
• Juan Chen
• gcx11
• Robert Bares
• Henrik Tunedal
• Nick
• Dmitry Borodin
• Efeturi Money
• Kevin Most
• Anastasiya Krasnoryadtseva
• Kristoffer Andersen
• Martin Petrov
• Matthew Gharrity
• Mike Samuel
• Mikhail Likholetov
• Segun Famisa
• Sinan Kozak
• Vadim Semenov
• Valeriy Vyrva
• Victor Turansky
• Yuku Kotani

Auteur de l’article original en anglais : Pavel Semyonov

Subscribe to Kotlin Blog updates

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

En envoyant ce formulaire, j'accepte que JetBrains s.r.o. (« JetBrains ») utilise mon nom, mon adresse e-mail et mes données de localisation pour m'envoyer des newsletters, y compris des communications commerciales, et pour traiter mes données personnelles à cet effet. J'accepte que JetBrains puisse traiter ces données au moyen de services tiers à cette fin et conformément à la Charte de confidentialité de JetBrains. Je comprends que je peux révoquer mon consentement à tout moment dans mon profil. De plus, un lien de désabonnement est inclus dans chaque e-mail.

Submit

Merci de votre abonnement !