You can find the complete list of changes in the change log<\/a>. As always, we\u2019d like to thank our external contributors<\/a>. Now let\u2019s dive into the details!<\/p>\n As you probably know, Kotlin decreases the possibility of <\/p>\n To solve this, starting from Kotlin 1.4, all runtime null checks will throw a Note that from a developer’s perspective, things won\u2019t change that much: the Kotlin code will throw exceptions with the same error messages as before. The type<\/em> of exception changes, but the information passed stays the same. For instance, the following code currently throws an Right before the After this change of behavior, the optimizers will be able to decrease the total number of null-checks present in the bytecode by removing repetitive null-checks when possible: since all checks throw the same NPE exception, only one can remain. During such optimizations, the specific helpful messages of NPEs can be lost, but that\u2019s the price to be paid for the gained performance benefits. Note that these optimizations are still to be implemented in the corresponding tools, and when implemented, there will be more details about that, but the change of the exception type makes it possible in the future.<\/p>\n Note that all new functions are added to the standard library in the “experimental” state.<\/p>\n A new duration and time measurement API is available for preview. Duration can be measured in a variety of units: seconds, milliseconds, nanoseconds, etc. The confusion between different units is a known source of bugs: if the API expects the duration stored as primitive value like Inline classes provide a very elegant solution to that: they bring both type system guarantees and an allocation-free approach. Now the API can use the This release brings support for The When using the The For more details about the implementation of the We\u2019re looking forward to your feedback!<\/p>\n The standard library now contains an API for bit manipulation (as usual, in the experimental state initially):<\/p>\n Note that similar extension functions for Int, Long, Short, Byte, and their unsigned counterparts have been added.<\/p>\n We plan to improve the Java-to-Kotlin converter to minimize the amount of \u201cred code\u201d one has to fix manually after the conversion. As the current converter almost always generates non-nullable types, you need to fix the nullability issues by hand afterward. It can often lead to runtime errors from nullability mismatch later.<\/p>\n The new, improved version of the Java-to-Kotlin converter tries to infer nullability more correctly based on the Java type usages in the code. Note that there\u2019s no goal to produce 100% error-free code. The goal is to decrease the number of compilation errors and to make the produced Kotlin code more convenient to work with. The new converter fixes many other known bugs, too; for instance, it now correctly handles implicit Java type casts.<\/p>\n In the future, the new converter is going to become the default one. In this release, it\u2019s available for preview. To turn it on, specify the Please give it a try and share your feedback with us!<\/p>\n We’ve improved how the Kotlin \u201cVariables\u201d view chooses the variables to display. As there\u2019s a lot of additional technical information in the bytecode, the Kotlin \u201cVariables\u201d view highlights only the relevant variables. Now it works better when you set a breakpoint inside a lambda (either inlined or non-inlined). Local variables inside the lambda, as well as captured variables from the outer context and parameters of the outer function, are correctly displayed:<\/p>\n You can now set a breakpoint at the end of the function, if needed:<\/p>\n Support for the \u201cEvaluate expression\u201d functionality in the debugger was improved for many non-trivial language features, such as local extension functions or accessors of member extension properties. Also, you can now modify variables via \u201cEvaluate expression\u201d:<\/p>\n Note that, alternatively, you can modify variables in the \u201cVariables\u201d view directly.<\/p>\n New intentions and inspections have been added. One of the goals of intentions is to help you learn how to write idiomatic Kotlin code. The following intention, for instance, suggests using the If the index isn\u2019t used, the loop can be automatically replaced with a for loop over elements.<\/p>\n IntelliJ IDEA now:<\/p>\n The general performance of IDE actions has been improved, and several known situations that were causing the UI to freeze (such as calling the \u201cMove\u201d refactoring on a file with a huge number of usages) have been fixed.<\/p>\n This update adds support for building and running Kotlin\/JS Gradle projects using the Under the hood, there have also been a series of performance improvements for Kotlin\/JS, improving the incremental compilation time for projects. This means that you can expect speedups of up to 30% when compared to 1.3.41.<\/p>\n Our improved integration with NPM means that projects are now resolved lazily and in parallel, and support for projects with transitive dependencies between compilations in the same project has been added.<\/p>\n The new version also brings with it changes in the structure and naming of generated artifacts. Generated artifacts are now bundled in the distributions folder, and they include the version number of the project and Dukat<\/a> allows the automatic conversion of TypeScript declaration files ( Kotlin\/JS now ships with experimental support for dukat integration for Gradle projects. With this integration, by running the build task in Gradle, typesafe wrappers are automatically<\/em> generated for npm dependencies and can be used from Kotlin.<\/p>\n Because dukat is still in a very early stage, its integration is disabled by default. Add the It was not easy but possible to notice that the version of Kotlin\/Native differed from the version of Kotlin. Not anymore! The version schemes for Kotlin and Kotlin\/Native are now aligned. This release uses version 1.3.50 for both Kotlin and Kotlin\/Native binaries, reducing the complexity.<\/p>\n This release brings more pre-imported Apple frameworks for all platforms, including macOS and iOS. The Kotlin\/Native compiler now includes actual bitcode in produced frameworks.<\/p>\n Several improvements have been made for interop. We now support the The standard library has been updated to support the The older functions We\u2019ve deprecated and removed the Finally, we are happy to share that the Kotlin\/Native compiler and the interop tool performance has been improved in this release.<\/p>\n Java compilation can now be included in Kotlin\/JVM targets of a multiplatform project by calling the newly added Kotlin’s New Project wizard now generates Gradle Kotlin DSL for new projects.<\/p>\n Debugging Kotlin\/Native code in IntelliJ IDEA Ultimate is now supported too! Try installing the new Native Debug for IntelliJ IDEA Ultimate<\/a> plugin. It should detect Kotlin\/Native run configurations and the debug action is supported:<\/p>\n This release adds multiple features and improvements in scripting and REPL support. Using Kotlin as a scripting language for your application is even easier! Now the scripting support works out of the box: we\u2019ve published a default JSR-223 implementation library, so to add Kotlin scripting support for your application, you only need to add Properties that are set via the JSR-223 API are now accessible from scripts as regular Kotlin properties (before, that you had to use the The Read more about scripting in KEEP-75<\/a>. You can find examples<\/a> in the Kotlin repository. Please share your feedback in the #scripting channel on the Kotlin Slack!<\/p>\n As always, you can try Kotlin online<\/strong> at play.kotl.in<\/a>.<\/p>\n If you run into any problems with the new release, you\u2019re welcome to ask for help on the forums<\/a>, on Slack (get an invite here<\/a>), or to report issues in the issue tracker<\/a>.<\/p>\n Let\u2019s Kotlin!<\/p>\n We want to especially thank Toshiaki Kameyama<\/a> for his ongoing work on providing many useful intentions and inspections for IntelliJ IDEA.<\/p>\n We\u2019d like to thank all our external contributors whose pull requests were included in this release:Null-check optimizations planned for Kotlin 1.4<\/h2>\n
NullPointerException<\/code>s by providing support for nullable types. However, because of interoperability with Java code, it\u2019s impossible to avoid NPEs completely. To help developers better understand the source of a nullability problem if it occurs, Kotlin compiler throws different types of runtime exceptions with clear error messages instead of pure NPEs. It turned out that this approach has its disadvantages: it reduces possible null check optimizations that can be performed either by the Kotlin compiler or by various kinds of bytecode processing tools, such as the Android R8 optimizer<\/a>.<\/p>\njava.lang.NullPointerException<\/code> instead of a KotlinNullPointerException<\/code>, IllegalStateException<\/code>, IllegalArgumentException<\/code>, and TypeCastException<\/code>. This applies to: the !!<\/code> operator, parameter null checks in the method preamble, platform-typed expression null checks, and the as<\/code> operator with a non-null type. This doesn\u2019t apply to lateinit<\/code> null checks and explicit library function calls like checkNotNull<\/code> or requireNotNull<\/code>.<\/p>\nIllegalStateException<\/code> with the error message \u201cJavaCode.getNull() must not be null\u201d:<\/p>\n\r\nfun main() {\r\n duplicate(JavaCode.getNull()) \/\/ 1\r\n}\r\n\r\nfun duplicate(s: String) = s + s\r\n<\/pre>\n\r\npublic class JavaCode {\r\n public static String getNull() { return null; }\r\n}\r\n<\/pre>\nduplicate<\/code> function call at line 1<\/code>, a special check is generated which throws this exception if the expression JavaCode.getNull()<\/code> stores null<\/code>. Starting with Kotlin 1.4, this code will throw a NullPointerException<\/code> instead with the same message, \u201cJavaCode.getNull() must not be null\u201d.<\/p>\nStandard library changes<\/h2>\n
Duration and time measurement API<\/h3>\n
Long<\/code>, one can erroneously pass the value in the wrong unit, and unfortunately the type system doesn\u2019t help prevent that. Creating a regular class to store duration solves this problem, but brings another one: additional allocations.<\/p>\nDuration<\/code> type, and all the clients will need to specify the time in the desired units explicitly. Since Duration<\/code> is declared as an inline class, no extra allocations are happening under the hood:<\/p>\n\r\nimport kotlinx.coroutines.delay\r\nimport kotlin.time.*\r\n\r\n@ExperimentalTime\r\nsuspend fun greetAfterTimeout(duration: Duration) {\r\n delay(duration.toLongMilliseconds())\r\n println("Hi!")\r\n}\r\n\r\n@UseExperimental(ExperimentalTime::class)\r\nsuspend fun main() {\r\n greetAfterTimeout(100.milliseconds)\r\n greetAfterTimeout(1.seconds)\r\n}\r\n<\/pre>\nMonoClock<\/code> which represents the monotonic clock<\/em>. The recommended approach to measuring time duration from a given point in your program is to use the monotonic clock, which doesn\u2019t depend on the system time. System time might be changed outside, and that might lead to erroneous behavior. The monotonic clock can only measure time difference between given time points, but doesn\u2019t know the \u201ccurrent time.\u201d<\/p>\nClock<\/code> interface provides a general API for measuring time intervals. MonoClock<\/code> is an object implementing Clock<\/code>; it provides the default source of monotonic time on different platforms.<\/p>\nClock<\/code> interface, you explicitly mark the time of action start, and later the time elapsed from the start point. It is especially convenient if you want to start and finish measuring time from different functions:<\/p>\n\r\nimport kotlin.time.*\r\n\r\n@UseExperimental(ExperimentalTime::class)\r\nfun main() {\r\n val clock = MonoClock\r\n val mark = clock.markNow() \/\/ might be inside the first function\r\n Thread.sleep(10) \/\/ action\r\n println(mark.elapsedNow()) \/\/ might be inside the second function\r\n}\r\n<\/pre>\nmeasureTimedValue<\/code> function allows you to measure the duration of a given action and get its result together with the duration of the elapsed time interval. It measures the elapsed time with MonoClock<\/code>.<\/p>\n\r\nimport kotlin.time.*\r\n\r\n@UseExperimental(ExperimentalTime::class)\r\nfun main() {\r\n val (value, duration) = measureTimedValue {\r\n Thread.sleep(100)\r\n 42\r\n }\r\n println(value) \/\/ 42\r\n println(duration) \/\/ e.g. 103 ms\r\n}\r\n<\/pre>\nDuration<\/code> class and the details of the Clock<\/code> interface and MonoClock<\/code> implementations for different platforms, please refer to the corresponding KEEP<\/a>. Note that this API is experimental and is subject to change based on your feedback. You will need to explicitly give your consent to use it by applying the corresponding annotations<\/a>.<\/p>\nFunctions for bit manipulation<\/h3>\n
\r\n@UseExperimental(ExperimentalStdlibApi::class)\r\nfun main() {\r\n val number = "1010000".toInt(radix = 2)\r\n println(number.countOneBits())\r\n println(number.countTrailingZeroBits())\r\n println(number.takeHighestOneBit().toString(2))\r\n println(number.rotateRight(3).toString(2))\r\n println(number.rotateLeft(3).toString(2))\r\n}\r\n<\/pre>\nIntelliJ IDEA support<\/h2>\n
Improved Java to Kotlin converter<\/h3>\n
Use New J2K (experimental)<\/code> flag in settings.<\/p>\nDebugging improvements<\/h3>\n
![\"debug_lambda_variables\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2019\/08\/kotlin-debug_lambda_variables.png\")
<\/p>\n![\"end_of_function_breakpoint\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2019\/08\/kotlin-end_of_function_breakpoint.png\")
<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2019\/08\/kotlin-evaluate_expression2.png\")
<\/p>\nNew intentions and inspections<\/h3>\n
indices<\/code> property rather than building a range of indices manually:<\/p>\n![\"\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2019\/08\/kotlin-indices2.png\")
<\/p>\n\n
lateinit<\/code> property of a primitive type with the by Delegates.notNull()<\/code> syntax.<\/li>\nArrays.equals()<\/code> or Array.deepEquals()<\/code>) and suggest replacing them with their Kotlin counterparts (like contentEquals<\/code> and contentDeepEquals<\/code>).<\/li>\n![\"deprecated_imports\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2019\/08\/kotlin-deprecated_imports.png\")
<\/p>\nKotlin\/JS<\/h2>\n
org.jetbrains.kotlin.js<\/code> plugin on Windows. Just like on other platforms, you can build and run your projects using Gradle tasks, dependencies from NPM required in your Gradle configuration are resolved and included, you can try out your applications using webpack-dev-server (e.g. by invoking the browserRun<\/code> Gradle task), and more. As with the other platforms, all of this can be used without having to manually install and manage a node, npm, or yarn distribution.<\/p>\narchiveBaseName<\/code> (which defaults to the project name), e.g. projectName-1.0-SNAPSHOT.js<\/code>.<\/p>\nDukat<\/h3>\n
.d.ts<\/code>) into Kotlin external declarations (and thus replaces the ts2kt<\/code> command-line tool). This makes it more comfortable to use libraries from the JavaScript ecosystem in a type-safe manner in Kotlin, by drastically reducing the need for manually writing wrappers for JS libraries.<\/p>\n![\"kotlin-dukat-preview\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2019\/08\/kotlin-kotlin-dukat-preview-1.png\")
<\/p>\nkotlin.js.experimental.generateKotlinExternals=true<\/code> line into the gradle.properties<\/code> file in a project root directory to turn on dukat for your project. We’ve prepared an example project<\/a> for it too, which demonstrates the use of dukat in Kotlin\/JS projects. Try it out and share your feedback<\/a> with us.<\/p>\nKotlin\/Native<\/h2>\n
kotlin.Deprecated<\/code> annotation when producing a framework, and the generated Objective-C headers code will not have warnings. The getOriginalKotlinClass()<\/code> function is added into the standard library to get a KClass<\/code> from an Objective-C class or protocols.<\/p>\nkotlin.reflect.typeOf()<\/code> function for Kotlin\/Native types. The new function executeAfter()<\/code> is added to the Worker<\/code> type to execute actions after a delay. In addition, you can call the processQueue()<\/code> function on the Worker<\/code> to process the tasks queue explicitly.<\/p>\nByteArray.stringFromUtf8()<\/code> and ByteArray.stringFromUtf8OrThrow()<\/code> are now deprecated. In the previous release, we added the ByteArray.decodeToString()<\/code> function (in the kotlin.text<\/code> package) to convert a UTF-8 string to a Kotlin string. That function does not support NULL-terminated strings, so to fix that, in 1.3.50 we’ve added a new function to deal with NULL-terminated UTF-8 strings easily. The ByteArray.toKString()<\/code> function (from the kotlinx.cinterop<\/code> package) can be used to turn a NULL-terminated UTF-8 string into a Kotlin string. You can pass start and end indices to the function if needed.<\/p>\nkotlin-platform-native<\/code> Gradle plugin in favor of the kotlin-multiplatform<\/code> Gradle plugin, so now you can easily benefit from all multiplatform project features. Check out the documentation<\/a> for the migration guide and more info<\/p>\nMultiplatform Projects<\/h2>\n
withJava()<\/code> function of the DSL. It will configure Java plugin to use the src\/<targetName>Main\/java<\/code> and src\/<targetName>Test\/java<\/code> paths by default. Here is a full example to create a Kotlin\/JVM target with enabled Java compilation:<\/p>\n\r\nplugins { \r\n kotlin("multiplatform") version "1.3.50"\r\n}\r\nkotlin {\r\n jvm {\r\n withJava()\r\n }\r\n}\r\n<\/pre>\n![\"debugging-kotlin-native-1.3.50\"](\"https:\/\/blog.jetbrains.com\/wp-content\/uploads\/2019\/08\/kotlin-debugging-kotlin-native-1.3.50.png\")
<\/p>\nScripting<\/h2>\n
kotlin-scripting-jsr223<\/code> as a dependency and use the javax.script<\/code> API with Kotlin.<\/p>\nbindings<\/code> map):<\/p>\n\r\nval engine = ScriptEngineManager().getEngineByExtension("kts")!!\r\nengine.put("z", 42)\r\nengine.eval("""println("answer = $z")""")\r\n<\/pre>\nkotlin-main-kts<\/code> artifact<\/a>, which was introduced in Kotlin 1.3 to simplify the creation and usage of the basic utility scripts, can now be used as a JSR-223 host as well. In addition to the annotations like Repository<\/code> and DependsOn<\/code> for resolving dependencies, it now supports the @Import<\/code> annotation instructing the scripting compiler to “import” another script into the current one:<\/p>\n\r\n\/\/ common.main.kts:\r\nval foo = "common foo"\r\n<\/pre>\n
\r\n\/\/ script.main.kts:\r\n@file:Import("common.main.kts")\r\nval bar = "bar with $foo"\r\n<\/pre>\nHow to update<\/h2>\n
\n
1.3.50<\/code> as the version for the compiler and the standard library. See the docs here<\/a>.<\/li>\nExternal Contributions<\/h2>\n
\n* Steven Sch\u00e4fer<\/a>
\n* pyos<\/a>
\n* Ivan Gavrilovic<\/a>
\n* Mads Ager<\/a>
\n* Ting-Yuan Huang<\/a>
\n* ilgonmic<\/a>
\n* Jiaxiang Chen<\/a>
\n* Mark Punzalan
\n* Jake Wharton
\n* Jeffrey van Gogh
\n* Peter Xu
\n* Amaury
\n* Benjamin Orsini
\n* Dereck Bridie
\n* Eduard Wolf
\n* George Gastaldi
\n* Juan Chen
\n* Kevin Peek
\n* KilianCallebaut
\n* Louis CAD
\n* Martin Petrov
\n* Matthew Runo<\/a>
\n* AJ Alt<\/a>
\n* Ty Smith
\n* ghedeon
\n* technoir
\n* Dat Trieu<\/a><\/p>\n","protected":false},"author":42,"featured_media":0,"comment_status":"open","ping_status":"open","template":"","categories":[896,907],"tags":[91],"cross-post-tag":[],"acf":[],"_links":{"self":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/kotlin\/5641"}],"collection":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/kotlin"}],"about":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/types\/kotlin"}],"author":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/users\/42"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/comments?post=5641"}],"version-history":[{"count":0,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/kotlin\/5641\/revisions"}],"wp:attachment":[{"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/media?parent=5641"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/categories?post=5641"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/tags?post=5641"},{"taxonomy":"cross-post-tag","embeddable":true,"href":"https:\/\/blog.jetbrains.com\/ja\/wp-json\/wp\/v2\/cross-post-tag?post=5641"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}