Last week, JetBrains released Kotlin 1.4 to the programming community. The update added some new language features but also put a strong focus on improving quality-of-life and performance, especially when paired with JetBrains’s own IntelliJ IDEA IDE.
So what can users expect from this new version? Read on.
The primary focus of this release was to improve performance across the board. Jetbrains (and the other contributors) fixed over 60 performance-related issues. This includes a lot of IDE bugs that were slowing things down, causing memory leaks and freezes. Autocomplete results now surface faster, one of the benefits of using a programming language created by an IDE company.
For performance slowdowns, nothing beats the compiler. Big compilation times drain developer productivity, so this release includes a brand new compiler. Kotlin code should compile to any of the supported target platforms faster. Additionally, they added an API that allows future extensions to the compiler.
Single abstract method (SAM) interfaces, aka functional interfaces, were previously only supported when the interface was written in Java. While Kotlin is interoperable with Java libraries, this could lead to complications where you would have to write your interface in Java and your implementations in Kotlin. With the increasing relevance of lambda expressions, this became increasingly burdensome and didn’t really fit in with Kotlin’s philosophy of remaining concise and improving developer happiness.
With SAM interfaces now supported directly in Kotlin, you can automatically convert a lambda expression that matches a SAM interface into an instance of a class that implements that interface without having to write the implementation class manually.
Explicit API mode
Library authors have an additional complication compared to devs writing applications: visibility. They need to make sure that their API methods are visible to anyone incorporating their functionality and anyone taking this library as a dependency needs to know what type any exposed variables are. Visible by default could mean a dev exposes something never meant to be seen by application developers, and explicitly hiding something previously visible would mean breaking changes.
With explicit API mode, all methods must have their visibility stated and all types must be specified. This is a compiler feature, either as a gradle setting or command line option, and can throw either warnings or errors, depending on how militant you want to be about your API library.
In line with its goal of making life easier for developers, Kotlin 1.4 adds a number of small language features that help avoid getting caught by errors of oversight:
- Mixing named and positional arguments in functions. Want to clarify an argument by explicitly mentioning its parameter name? Now you can without causing errors. For example `reformat(‘This is a String!’, uppercaseFirstLetter = false , ‘-‘)` Previously, you could only pass values in the order specified in the method.
- Trailing commas. In any comma-separated list of values or parameters, you can now include a comma at the end of the list without causing errors. Helpful for lists that are regularly edited and change over time.
- Use `continue` and `break` within `when` loops without labeling. These keywords can now just be used as is without labeling with `@LOOP`.
Will these new features continue Kotlin’s growth or just please the existing base? Let us know in the comment if you think any of these additions make Kotlin a Java killer or if they are just riding the hype train.Tags: kotlin