https://kotlinlang.org/
2019/8/22 Kotlin 1.3.50 est sorti: tada :: tada :: tada: Kotlin 1.3.50 released
ensemble Kotlin coroutiees1.3.0 a également été publié! (Je ne toucherai pas à celui-ci cette fois ..)
Kotlin Fest 2019 est également sorti juste avant l'événement! (Ceux qui sont montés sur scène ont eu du mal à modifier les matériaux pour qu'ils correspondent à 1.3.50 juste avant ..)
J'ai traduit le blog de publication abrégé ci-dessous. Je ne suis pas très habitué donc je suis désolé s'il y a une erreur de traduction: arc:
Kotlin réduit la possibilité de NullPointerExceptions en prenant en charge les types nullables, mais il est impossible d'éviter complètement NPE en raison de son interopérabilité avec le code Java. Pour aider les développeurs à mieux comprendre la cause de la possibilité nulle, le compilateur Kotlin lève différents types d'exceptions d'exécution avec un message d'erreur clair au lieu d'un NPE pur. Cette approche s'est avérée problématique. Cela interfère avec l'optimisation des vérifications nulles qui peuvent être effectuées soit par le compilateur Kotlin, soit par divers types d'outils de traitement de bytecode tels que l'optimiseur Android R8.
Pour résoudre ce problème, à partir de Kotlin 1.4, toutes les vérifications null à l'exécution lancent java.lang.NullPointerException au lieu de KotlinNullPointerException, IllegalStateException, IllegalArgumentException et TypeCastException. Il s'applique à:
--Vérifier les paramètres de préambule d'opérateur et de méthode null
Du point de vue d'un développeur, cela ne change pas grand-chose. Le code Kotlin lève une exception avec le même message d'erreur qu'auparavant. Les types d'exceptions changent, mais pas les informations transmises. Le code suivant lève actuellement une IllegalStateException avec le message d'erreur «avaCode.getNull () ne doit pas être nul».
fun main() {
duplicate(JavaCode.getNull()) // 1
}
fun duplicate(s: String) = s + s
public class JavaCode {
public static String getNull() { return null; }
}
Une vérification spéciale fonctionne qui lève une exception lorsque JavaCode.getNull () stocke null. À partir de Kotlin 1.4, ce code lève une NullPointerException au lieu du message d'erreur «JavaCode.getNull () ne doit pas être nul».
Cette modification peut réduire les itérations de vérification nulles et réduire le nombre de vérifications nulles présentes dans le code d'octet.
: information_source: Toutes les fonctions nouvellement ajoutées sont des fonctions "expérimentales"
Duration and time measurement API Une version préliminaire de la nouvelle API de mesure de la durée et du temps est disponible. La durée peut être mesurée en différentes unités telles que secondes, millisecondes, nanosecondes, etc. Différentes unités sont déroutantes et provoquent des bugs. Si l'API s'attend à ce qu'une période de temps soit stockée en tant que valeur primitive de type Long, le système de type d'unité ne contribuera pas à empêcher cela. La création d'une classe régulière et l'enregistrement de la période résout ce problème, mais cela entraîne des problèmes d'allocation supplémentaires.
Les classes en ligne fournissent une solution sophistiquée aux problèmes ci-dessus. Il fournit à la fois une garantie de système de type et une approche non attribuée. L'API pourra désormais utiliser le type Durée, qui oblige tous les clients à spécifier explicitement l'heure dans l'unité souhaitée. La durée est déclarée en tant que classe en ligne, il n'y a donc pas d'allocations supplémentaires en interne.
import kotlinx.coroutines.delay
import kotlin.time.*
@ExperimentalTime
suspend fun greetAfterTimeout(duration: Duration) {
delay(duration.toLongMilliseconds())
println("Hi!")
}
@UseExperimental(ExperimentalTime::class)
suspend fun main() {
greetAfterTimeout(100.milliseconds)
greetAfterTimeout(1.seconds)
}
Cette version prend en charge Mono Clock, qui représente une horloge monotone. L'approche recommandée pour mesurer la durée à partir d'un point particulier du programme consiste à utiliser une horloge monotone indépendante de l'heure du système. L'heure du système est sujette à des modifications externes, ce qui peut entraîner un comportement incorrect. L'horloge monotone ne peut mesurer que la différence de temps entre des points spécifiés dans le temps, mais elle ne connaît pas «l'heure actuelle».
L'interface Clock fournit une API commune pour mesurer les intervalles de temps. MonoClock est un objet qui implémente Clock. Fournit une source par défaut de temps monotone sur différentes plates-formes.
Lorsque vous utilisez l'interface Horloge, marquez explicitement l'heure de début de l'action et marquez plus tard le temps écoulé à partir du point de départ. Ceci est particulièrement utile pour commencer et terminer les mesures de temps à partir de diverses fonctionnalités.
import kotlin.time.*
@UseExperimental(ExperimentalTime::class)
fun main() {
val clock = MonoClock
val mark = clock.markNow() // might be inside the first function
Thread.sleep(10) // action
println(mark.elapsedNow()) // might be inside the second function
}
Vous pouvez utiliser la fonction measureTimedValue pour mesurer la durée d'une action particulière et obtenir le résultat avec la durée de l'intervalle de temps écoulé. Mesurez le temps écoulé avec MonoClock.
import kotlin.time.*
@UseExperimental(ExperimentalTime::class)
fun main() {
val (value, duration) = measureTimedValue {
Thread.sleep(100)
42
}
println(value) // 42
println(duration) // e.g. 103 ms
}
Pour plus d'informations sur l'implémentation de la classe Duration, ainsi que sur l'interface Clock et l'implémentation MonoClock sur différentes plates-formes, voir KEEP Veuillez consulter .md). Veuillez noter que cette API est expérimentale et sujette à modification en fonction des commentaires.
Une API pour la manipulation de bits a été implémentée expérimentalement dans la bibliothèque standard.
@UseExperimental(ExperimentalStdlibApi::class)
fun main() {
val number = "1010000".toInt(radix = 2)
println(number.countOneBits())
println(number.countTrailingZeroBits())
println(number.takeHighestOneBit().toString(2))
println(number.rotateRight(3).toString(2))
println(number.rotateLeft(3).toString(2))
}
Nous prévoyons d'améliorer le convertisseur Java vers Kotlin pour minimiser la quantité de code qui est manuellement modifiée après la conversion. La plupart des convertisseurs actuels génèrent des types non nullables, donc les problèmes de nullabilité devront être résolus manuellement plus tard. Dans de nombreux cas, une incompatibilité de nullabilité peut entraîner des erreurs d'exécution ultérieurement.
Une nouvelle version améliorée du convertisseur Java vers Kotlin tente de deviner plus précisément la nullité en fonction de l'utilisation de types Java dans votre code. Il n'y a aucun objectif d'écrire du code 100% sans erreur. Le but est de réduire le nombre d'erreurs de compilation et de rendre le code Kotlin généré plus facile à utiliser. Le nouveau convertisseur corrige également de nombreux autres bogues connus. Par exemple, il gère désormais correctement les conversions de type Java implicites.
À l'avenir, le nouveau convertisseur sera le convertisseur par défaut. Disponible en aperçu dans cette version. Pour l'activer, spécifiez l'indicateur "Utiliser un nouveau J2K (expérimental)" dans les paramètres.
Amélioration de la façon dont la vue «Variables» de Kotlin sélectionne les variables affichées. En raison du grand nombre d'informations techniques supplémentaires dans le bytecode, seules les variables pertinentes sont mises en évidence dans la vue «Variables». La définition de points d'arrêt dans le lambda (en ligne ou non en ligne) fonctionne désormais mieux. Les paramètres des variables locales dans le lambda et les variables et fonctions externes capturées à partir du contexte externe s'affichent correctement.
Vous pouvez définir un point d'arrêt à la fin de la fonction, si vous le souhaitez.
La prise en charge de la fonctionnalité «Evaluer les expressions» a été améliorée dans de nombreuses fonctionnalités linguistiques importantes, telles que les extensions locales et les accesseurs pour les propriétés d'extension des membres. De plus, vous pouvez désormais modifier les variables avec la fonction "Evaluer l'expression".
De nouvelles intentions et inspections ont été ajoutées. L'un des objectifs est de vous aider à apprendre à écrire du code Kotlin idiomatique. Par exemple, nous suggérons d'utiliser la propriété indexes au lieu de construire manuellement la plage d'index.
Si vous n'utilisez pas d'index, les boucles peuvent être automatiquement remplacées par des éléments pour les boucles.
Kotlin/JS
Dukat Vous pouvez convertir automatiquement les fichiers de déclaration TypeScript (.d.ts) en déclarations externes Kotlin (remplace l'outil de ligne de commande ts2kt). La nécessité d'écrire manuellement des wrappers pour la bibliothèque JS est considérablement réduite, de sorte que Kotlin peut utiliser confortablement les bibliothèques de l'écosystème JavaScript d'une manière sécurisée.
Kotlin / JS soutiendra expérimentalement l'intégration dukat du projet Gradle. En exécutant une tâche de construction dans Gradle, un wrapper de type sécurisé est automatiquement généré pour la dépendance npm et peut être utilisé à partir de Kotlin.
Kotlin/Native --Kotlin / Version native unifiée avec Kotlin
La compilation Java peut désormais être incluse dans les cibles Kotlin / JVM pour les projets multi-plateformes en appelant la fonction withJava () nouvellement ajoutée dans DSL. Configurez le plug-in Java pour utiliser les chemins src /
plugins {
kotlin("multiplatform") version "1.3.50"
}
kotlin {
jvm {
withJava()
}
}
L'assistant de nouveau projet de Kotlin génère désormais un DSL Gradle Kotlin pour les nouveaux projets.
Le débogage de code Kotlin / Native dans IntelliJ IDEA Ultimate est désormais également pris en charge. Native Debug for IntelliJ IDEA Ultimate
Scripting Plusieurs fonctionnalités ont été ajoutées pour améliorer la prise en charge des scripts et des REPL. Une bibliothèque qui implémente la valeur par défaut JSR-223 simplement en ajoutant kotlin-scripting-jsr223 en tant que dépendance et en utilisant javax Il sera disponible.
Les propriétés définies via l'API JSR-223 sont désormais accessibles à partir de scripts en tant que propriétés Kotlin classiques (auparavant, vous deviez utiliser une carte de liaison).
Référence: Essayez l'implémentation Java JSR-223
val engine = ScriptEngineManager().getEngineByExtension("kts")!!
engine.put("z", 42)
engine.eval("""println("answer = $z")""")
En plus des annotations telles que Repository et DependsOn pour la résolution des dépendances, nous prenons désormais en charge les annotations @Import qui indiquent au compilateur de script "d'importer" un autre script dans le script actuel.
// common.main.kts:
val foo = "common foo"
// script.main.kts:
@file:Import("common.main.kts")
val bar = "bar with $foo"
Kotlin 1.4 est sur le point d'être vu. Kotlin / JS et Kotlin / Native sont également activement améliorés, et j'ai hâte de voir comment Kotlin se développera à l'avenir. Je continuerai à regarder: lunettes de soleil:
Cet article est également compatible avec Kotlin 1.3.50! Traitement asynchrone de la communication HTTP avec les coroutines (Async, Await) d'Android + Kotlin 1.3
Recommended Posts