![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2020\/07\/Blog_Banners_m3_1500h751.png\")
<\/p>\n
Les modifications de la biblioth\u00e8que standard dans la version 1.4-M3 portent sur les points suivants\u00a0:<\/p>\n
- \n
- Les biblioth\u00e8ques JVM incluent maintenant le descripteur
module-info<\/code><\/li>\n- \nLes interfaces fonctionnelles<\/a> sont ajout\u00e9s \u00e0 la biblioth\u00e8que standard<\/li>\n
- \nDe nouvelles op\u00e9rations de collections pour couvrir des cas concrets<\/li>\n
- \nL’annotation
@Throws<\/code><\/a> dans la biblioth\u00e8que commune<\/li>\n- L’abandon de certaines fonctions sur les tableaux de valeurs en virgule flottante<\/li>\n<\/ul>\n
Vous trouverez la liste compl\u00e8te des modifications dans le journal des modifications<\/a>. Comme toujours, nous sommes extr\u00eamement reconnaissants envers nos contributeurs externes.<\/p>\n
Nous comptons sur vous pour essayer la preview et nous faire part de vos retours.<\/p>\n
<\/p>\n
Les artefacts de la biblioth\u00e8que standard comprennent d\u00e9sormais des descripteurs module-info<\/h2>\n
Depuis Java\u00a09, vous pouvez modulariser votre application gr\u00e2ce au projet Jigsaw. L’outil jlink<\/strong><\/a> vous permet de g\u00e9n\u00e9rer une image Java runtime personnalis\u00e9e contenant uniquement les modules de la plateforme qui sont n\u00e9cessaires pour votre application. Auparavant, il \u00e9tait possible d’utiliser
jlink<\/code> avec les artefacts de biblioth\u00e8que standard de Kotlin, mais il fallait utiliser des artefacts s\u00e9par\u00e9s (ceux avec le classificateur "modular") et la configuration n’\u00e9tait pas simple. L’impossibilit\u00e9 d’inclure des descripteurs de modules dans les principaux artefacts \u00e9tait due \u00e0 des probl\u00e8mes li\u00e9s \u00e0 l’outillage d’Android, qui sont maintenant r\u00e9solus.<\/p>\nKotlin 1.4 ajoute les informations du module
module-info.java<\/code> aux artefacts de biblioth\u00e8que standard par d\u00e9faut, afin que vous puissiez les utiliser facilement avecjlink<\/code>. Sous Android, veillez \u00e0 utiliser le plugin Android Gradle version 3.2 ou sup\u00e9rieure, qui peut traiter correctement les fichiers jar avec module-info.<\/p>\nfun interfaces dans la biblioth\u00e8que standard<\/h2>\n
Kotlin 1.4 prend en charge les conversions SAM pour les classes Kotlin<\/a>. Vous pouvez marquer une interface ayant une seule m\u00e9thode abstraite comme
fun interface<\/code>, puis passer un lambda comme argument lorsque cette interface est attendue comme param\u00e8tre. Dans la biblioth\u00e8que standard, les interfaces suivantes sont d\u00e9sormais d\u00e9clar\u00e9es commefun interface<\/code>\u00a0:<\/p>\n- \n
Comparator<\/code><\/li>\nReadOnlyProperty<\/code><\/li>\nPropertyDelegateProvider<\/code> (qui a \u00e9t\u00e9 introduit dans la version 1.4-M2<\/a>)<\/li>\n<\/ul>\nVous pouvez utiliser un constructeur SAM qui prend un lambda comme param\u00e8tre pour cr\u00e9er une instance. Le code qui en r\u00e9sulte est bien plus simple\u00a0:<\/p>\n
![](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2020\/07\/fun_interface-1.png\")
<\/p>\nOp\u00e9rations de collections<\/h2>\n
- \n
- Une nouvelle fonction
sumOf<\/code> prend une fonction de s\u00e9lecteur et renvoie une somme de ses valeurs sur tous les \u00e9l\u00e9ments d’une collection. Elle est assez similaire aux fonctions existantessumBy<\/code> etsumByDouble<\/code>. La principale diff\u00e9rence est que la nouvelle fonctionsumOf<\/code> accepte des s\u00e9lecteurs avec diff\u00e9rents types de retour, ce qui permet de traiter les sommes de diff\u00e9rents types de la m\u00eame mani\u00e8re. Plus pr\u00e9cis\u00e9ment, sumOf produit des sommes des typesInt<\/code>,Long<\/code>,Double<\/code>,UInt<\/code>,ULong<\/code>. Sur la JVM,BigInteger<\/code> etBigDecimal<\/code> sont \u00e9galement disponibles.\n\r\ndata class OrderItem(val name: String, val price: Double, val count: Int)\r\n\r\nfun main() {\r\n\/\/sampleStart\r\n val order = listOf<OrderItem>(\r\n OrderItem("Cake", price = 10.0, count = 1),\r\n\tOrderItem("Coffee", price = 2.5, count = 3),\r\n OrderItem("Tea", price = 1.5, count = 2))\r\n \r\n val total = order.sumOf { it.price * it.count} \/\/ Double\r\n val count = order.sumOf { it.count } \/\/ Int\r\n\/\/sampleEnd\r\n println("You've ordered $count items that cost $total in total")\r\n}\r\n<\/pre>\n<\/li>\n- \nLes fonctions
min<\/code> etmax<\/code> ont \u00e9t\u00e9 renomm\u00e9es enminOrNull<\/code> etmaxOrNull<\/code>. Depuis leur introduction dans la version 1.0,min<\/code> etmax<\/code> ont renvoy\u00e9null<\/code> pour les collections vides. Ceci est contraire \u00e0 la convention de nommage utilis\u00e9e dans l’API des collections de Kotlin\u00a0: les fonctions sans le suffixe*OrNull<\/code> l\u00e8vent une exception si la collection r\u00e9ceptrice est vide. Pour obtenir unnull<\/code> \u00e0 la place, vous devez utiliser la version*OrNull<\/code> de la fonction, par exemplefirstOrNull<\/code>.
\nNous avons donc d\u00e9cid\u00e9 de modifier progressivement le comportement demin<\/code> etmax<\/code>. Dans la version 1.4-M3, nous ajoutonsminOrNull<\/code> etmaxOrNull<\/code> comme synonymes demin<\/code> etmax<\/code> et nous d\u00e9marrons le cycle de r\u00e9vision pourmin<\/code> etmax<\/code>, en vue de les r\u00e9introduire avec des types de retour non null.\n<\/li>\n- \nNous avons introduit les fonctions
minOf<\/code> etmaxOf<\/code> qui renvoient la valeur minimale ou maximale de la fonction de s\u00e9lecteur donn\u00e9e sur les \u00e9l\u00e9ments de la collection. Ces fonctions apportent une solution \u00e0 la situation dans laquelle il \u00e9tait n\u00e9cessaire d’\u00e9criremap { selector }.max()!!<\/code> oumaxBy { selector }!!.selector<\/code> (oumin<\/code> etminBy<\/code>).<\/p>\n\r\ndata class OrderItem(val name: String, val price: Double, val count: Int)\r\n\r\nfun main() {\r\n\/\/sampleStart\r\n val order = listOf<OrderItem>(\r\n OrderItem("Cake", price = 10.0, count = 1),\r\n OrderItem("Coffee", price = 2.5, count = 3),\r\n OrderItem("Tea", price = 1.5, count = 2))\r\n \r\n val highestPrice = order.maxOf { it.price }\r\n\/\/sampleEnd \r\n println("The most expensive item in the order costs $highestPrice")\r\n}\r\n<\/pre>\nPar souci de coh\u00e9rence avec l’API existante, nous avons \u00e9galement ajout\u00e9
minOfWith<\/code> etmaxOfWith<\/code>, qui prennent unComparator<\/code> comme argument.
\nLes quatre nouvelles fonctions suivent la convention non-null que nous avons d\u00e9crite ci-dessus : elles lancent des exceptions sur les collections vides et ont des versions*OrNull<\/code> qui renvoientnull<\/code> dans ce cas.\n<\/li>\n- \nDe nouvelles surcharges pour
flatMap<\/code> etflatMapTo<\/code> vous permettent d’utiliser des transformations avec des types de retour ne correspondant pas au type de r\u00e9cepteur, \u00e0 savoir\u00a0:<\/p>\n- \n
- transformations en
Sequence<\/code> pourIterable<\/code>,Array<\/code> etMap<\/code><\/li>\n- transformations en
Iterable<\/code> pourSequence<\/code><\/li>\n<\/ul>\n\r\nfun main() {\r\n\/\/sampleStart\r\n val list = listOf("kot", "lin")\r\n val lettersList = list.flatMap { it.asSequence() }\r\n val lettersSeq = list.asSequence().flatMap { it.toList() }\r\n\/\/sampleEnd \r\n println(lettersList)\r\n println(lettersSeq.toList())\r\n}\r\n<\/pre>\n<\/li>\n- \n Une nouvelle fonction
flatMapIndexed<\/code> a \u00e9t\u00e9 ajout\u00e9e comme contrepartie deflatMap<\/code>. Comme vous le savez peut-\u00eatre d\u00e9j\u00e0,Indexed<\/code> dans le nom d’une fonction de traitement de collection signifie que l’op\u00e9ration appliqu\u00e9e a l’index de l’\u00e9l\u00e9ment comme param\u00e8tre.<\/p>\n\r\nfun main() {\r\n\/\/sampleStart\r\n val list = listOf("hello", "kot", "lin", "world")\r\n val kotlin = list.flatMapIndexed { index, item ->\r\n if (index in 1..2) item.toList() else emptyList() \r\n }\r\n\/\/sampleEnd\r\n println(kotlin)\r\n}\r\n<\/pre>\n<\/li>\n<\/ul>\nAnnotation @Throws commune<\/h2>\n
Bien que Kotlin n’ait pas d’exceptions v\u00e9rifi\u00e9es<\/a>, il utilise l’annotation code>@Throws<\/code<\/a><\/a> pour assurer l’interop\u00e9rabilit\u00e9 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<\/code>) et Native (kotlin.native.Throws<\/code>). \u00c0 partir de la version 1.4-M3, l’annotation@Throws<\/code> est disponible dans la biblioth\u00e8que commune directement au sein du packagekotlin<\/code> (kotlin.Throws<\/code>), ce qui vous permet de l’utiliser dans le code commun.<\/p>\n@Throws dans les fonctions de suspension pour Swift et Objective-C<\/h3>\n
Dans la version1.4-M1, nous avions annonc\u00e9 des changements relatifs au traitement des exceptions dans l’interop Objective-C\/Swift<\/a>\u00a0: d\u00e9sormais,
NSError<\/code> n’est lanc\u00e9 que pour les exceptions qui sont des instances de classes sp\u00e9cifi\u00e9es comme param\u00e8tres de l’annotation@Throws<\/code> (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<\/a>. Avec la version 1.4-M3, il y a quelques changements dans le comportement des fonctions de suspension annot\u00e9es avec@Throws<\/code>\u00a0:<\/p>\n- \n
- Si vous avez un
suspend fun<\/code> annot\u00e9 avec@Throws<\/code>, vous devez sp\u00e9cifierCancellationException::class<\/code> comme param\u00e8tre de l’annotation@Throws<\/code>. Sinon, vous obtiendrez une erreur de compilation.<\/li>\n- S’il n’y a pas d’annotation
@Throws<\/code> sur unsuspend fun<\/code>, il utilisera implicitement@Throws(CancellationException::class)<\/code> lorsque vous l’appellez depuis Swift.<\/li>\n<\/ul>\n\u00c9galit\u00e9 dans les tableaux de valeurs \u00e0 virgule flottante<\/h2>\n
Beaucoup d’entre vous connaissent ces fonctions d’extension pratiques pour les types de conteneurs\u00a0:
contains<\/code>,indexOf<\/code>, etlastIndexOf<\/code>. Il y a quelque temps, nous avons d\u00e9couvert que leur comportement sur les tableaux \u00e0 virgule flottante (FloatArray<\/code> etDoubleArray<\/code>) peut \u00eatre discutable et sembler incorrect.
\nEn effet, ils utilisent la norme IEEE 754<\/a> pour l’arithm\u00e9tique en virgule flottante. Cette norme d\u00e9finit les r\u00e8gles d’\u00e9galit\u00e9 suivantes pour les cas particuliers\u00a0:<\/p>\n- \n
NaN<\/code> n’est pas \u00e9gal \u00e0<\/strong>NaN<\/code><\/li>\n-0.0<\/code> est \u00e9gal \u00e0<\/strong>0.0<\/code><\/li>\n<\/ul>\nCes r\u00e8gles peuvent entra\u00eener des r\u00e9sultats inattendus, par exemple\u00a0:<\/p>\n
\r\nfun main() {\r\n\/\/sampleStart\r\n val darray = doubleArrayOf(Double.NaN, 0.0)\r\n println (darray.contains(darray[0])) \/\/ false!\r\n\/\/sampleEnd\r\n}\r\n<\/pre>\nDe plus, un tel comportement n’est pas coh\u00e9rent avec la fa\u00e7on dont ces m\u00eames fonctions op\u00e8rent sur les listes, car elles utilisent l’\u00e9galit\u00e9 ordre total <\/em>:<\/p>\n
\r\nfun main() {\r\n\/\/sampleStart\r\n val listOfDouble: List<Double> = listOf(0.0, Double.NaN)\r\n val listFromArray: List<Double> = doubleArrayOf(0.0, Double.NaN).asList()\r\n\r\n println(listOfDouble.contains(Double.NaN)) \/\/ true\r\n println(listFromArray.contains(Double.NaN)) \/\/ false dans les versions pr\u00e9c\u00e9dentes\r\n\/\/sampleEnd\r\n}\r\n<\/pre>\nDans la version 1.4-M3, nous commen\u00e7ons le cycle de r\u00e9vision des fonctions d’extension
contains<\/code>,indexOf<\/code> etlastIndexOf<\/code> deFloatArray<\/code> etDoubleArray<\/code>. Lorsque vous essayerez de les utiliser, vous verrez des avertissements avec des instructions pour le remplacement des utilisations de ces fonctions.
\nDans les prochaines versions, nous allons relever le niveau de d\u00e9pr\u00e9ciation \u00e0ERROR<\/code> et supprimer ces fonctions de l’API publique.<\/p>\nConversion de KType en Java Type<\/h2>\n
Dans Kotlin 1.3.40, nous avons ajout\u00e9 une fonction
typeOf<\/code><\/a> \u00e0 la biblioth\u00e8que standard. Cette fonction renvoie une repr\u00e9sentation d’ex\u00e9cution du type r\u00e9ifi\u00e9 donn\u00e9T<\/code> comme une instance deKType<\/code><\/a>. Cependant, dans de nombreux cas d’utilisation concrets, vous devez travailler avec les objetsjava.lang.reflect.Type<\/code><\/a> de Java reflection plut\u00f4t qu’avecKType<\/code>. Il \u00e9tait d\u00e9j\u00e0 possible d’effectuer la conversion n\u00e9cessaire, mais il fallait utiliser toute la d\u00e9pendancekotlin-reflect<\/code>. Nous avons maintenant mis \u00e0 jour la biblioth\u00e8que standard avec un moyen de convertirKType<\/code> enType<\/code> Java \u2013 une propri\u00e9t\u00e9 d’extensionKType.javaType<\/code> qui renvoie unType<\/code> Java\u00a0:<\/p>\n\r\nimport kotlin.reflect.javaType\r\nimport kotlin.reflect.typeOf\r\n\r\n@OptIn(ExperimentalStdlibApi::class)\r\ninline fun <reified T> accessReifiedTypeArg() {\r\n val kType = typeOf<T>()\r\n println("Kotlin type: $kType")\r\n println("Java type: ${kType.javaType}")\r\n}\r\n\r\n@OptIn(ExperimentalStdlibApi::class)\r\nfun main() {\r\n accessReifiedTypeArg<String>()\r\n \/\/ Kotlin type: kotlin.String\r\n \/\/ Java type: class java.lang.String\r\n \r\n accessReifiedTypeArg<List<String>>()\r\n \/\/ Kotlin type: kotlin.collections.List<kotlin.String>\r\n \/\/ Java type: java.util.List<java.lang.String>\r\n}\r\n<\/pre>\nNotez que jusqu’\u00e0 pr\u00e9sent, le
Type<\/code> Java obtenu ne se comporte pas correctement dans certains cas particuliers (comme les param\u00e8tres de type annot\u00e9s ou la variance declaration-site), doncKType.javaType<\/code> reste exp\u00e9rimental. Vous pouvez trouver plus de d\u00e9tails sur les cas non pris en charge dans ce ticket<\/a>.<\/p>\nCompatibilit\u00e9<\/h2>\n
Notez que Kotlin 1.4 n’est pas r\u00e9trocompatible avec la version 1.3 dans certains cas particuliers. Tous ces cas ont \u00e9t\u00e9 soigneusement examin\u00e9s par le comit\u00e9 du langage et seront r\u00e9pertori\u00e9s dans le "guide de compatibilit\u00e9" (similaire \u00e0 celui-ci<\/a>). Pour le moment, vous pouvez trouver cette liste dans YouTrack<\/a>.<\/p>\n
Notes de pr\u00e9-version<\/h3>\n
\n Notez que les garanties de r\u00e9trocompatibilit\u00e9 ne concernent pas les versions pr\u00e9liminaires. Les fonctionnalit\u00e9s et l’API peuvent changer dans les versions ult\u00e9rieures. Lorsque nous arriverons au release candidate final, tous les binaires produits par les versions pr\u00e9liminaires seront interdits par le compilateur et vous devrez recompiler tout ce qui a \u00e9t\u00e9 compil\u00e9 par la version 1.4 \u2011 Mx.\n<\/p><\/blockquote>\n
Comment essayer les derni\u00e8res fonctionnalit\u00e9s<\/h2>\n
Comme toujours, vous pouvez essayer Kotlin en ligne<\/strong> sur play.kotl.in<\/a>.<\/p>\n
Dans IntelliJ IDEA<\/strong> et Android Studio<\/strong>, vous pouvez mettre \u00e0 jour le plugin Kotlin vers la version 1.4-M3. Voir comment proc\u00e9der<\/a>.<\/p>\n
Si vous souhaitez travailler sur des projets existants qui ont \u00e9t\u00e9 cr\u00e9\u00e9s avant d’installer la version pr\u00e9liminaire, vous devez configurer votre build pour la version Prewiew dans Gradle ou Maven<\/a>.<\/p>\n
Vous pouvez t\u00e9l\u00e9charger le compilateur de ligne de commande<\/strong> sur la page Github de la version 1.4-M3<\/a>.<\/p>\n
Vous pouvez utiliser les versions suivantes des biblioth\u00e8ques<\/strong> publi\u00e9es avec cette version\u00a0:<\/p>\n
- \n
- kotlinx.atomicfu<\/a> version\u00a0: 0.14.3-1.4-M3<\/a><\/li>\n
- kotlinx.coroutines<\/a> version\u00a0: 1.3.7-1.4-M3<\/a><\/li>\n
- kotlinx.serialization<\/a> version\u00a0: 0.20.0-1.4-M3<\/a><\/li>\n
- ktor<\/a> version\u00a0: 1.3.2-1.4-M3<\/a><\/li>\n<\/ul>\n
Les d\u00e9tails de la version et la liste des biblioth\u00e8ques compatibles sont \u00e9galement disponibles ici<\/a>.<\/p>\n
Partager votre avis<\/h2>\n
Nous vous remercions pour tous vos rapports de bugs dans notre outil de suivi<\/a> et ferons de notre mieux pour corriger tous les probl\u00e8mes les plus importants avant la version finale.<\/p>\n
Nous vous invitons \u00e0 rejoindre le canal #eap<\/a><\/em> sur notre Slack Kotlin<\/a> (demandez une invitation ici<\/a>). Sur ce canal, vous pouvez poser vos questions, participer aux discussions et recevoir es notifications sur les nouveaux builds.<\/p>\n
Faison \u00e9voluer Kotlin ensemble !<\/p>\n
Contributions externes<\/h2>\n
Nous remercions tous nos contributeurs externes dont les requ\u00eates pull ont \u00e9t\u00e9 incluses dans cette version\u00a0:<\/p>\n
- \n
- Toshiaki Kameyama<\/a><\/li>\n
- Steven Sch\u00e4fer<\/a><\/li>\n
- Jinseong Jeon<\/a><\/li>\n
- pyos<\/a><\/li>\n
- Mark Punzalan<\/a><\/li>\n
- rapturemain<\/a><\/li>\n
- Vitaly Tihonov<\/a><\/li>\n
- Mads Ager<\/a><\/li>\n
- Subroh Nishikori<\/a><\/li>\n
- Juan Chen<\/a><\/li>\n
- gcx11<\/a><\/li>\n
- Robert Bares<\/a><\/li>\n
- Henrik Tunedal<\/a><\/li>\n
- Nick<\/a><\/li>\n
- Dmitry Borodin<\/a><\/li>\n
- Efeturi Money<\/a><\/li>\n
- Kevin Most<\/a><\/li>\n
- Anastasiya Krasnoryadtseva<\/a><\/li>\n
- Kristoffer Andersen<\/a><\/li>\n
- Martin Petrov<\/a><\/li>\n
- Matthew Gharrity<\/a><\/li>\n
- Mike Samuel<\/a><\/li>\n
- Mikhail Likholetov<\/a><\/li>\n
- Segun Famisa<\/a><\/li>\n
- Sinan Kozak<\/a><\/li>\n
- Vadim Semenov<\/a><\/li>\n
- Valeriy Vyrva<\/a><\/li>\n
- Victor Turansky<\/a><\/li>\n
- Steven Sch\u00e4fer<\/a><\/li>\n
- kotlinx.coroutines<\/a> version\u00a0: 1.3.7-1.4-M3<\/a><\/li>\n
- S’il n’y a pas d’annotation
- transformations en
- \nLes fonctions