Kotlin for Server-Side Frameworks News: Kotlin Premier Event Presentation Highlights
The Kotlin Online Event is over. But we thought we’d give a quick recap of the two server-side talks: What’s New in Ktor 2.0 and Spring Native with Kotlin. In these presentations, Hadi Hariri and Sébastien Deleuze took us on a pair of deep dives into the multiplatform abilities of the frameworks.
What’s New in Ktor 2.0
This talk covered some of the exciting new things that are coming in Ktor 2.0. Ktor 2.0 is currently in Beta, but it already includes features that should help simplify development and lay the groundwork for many new things to come.
So, what’s new in Ktor 2.0? It may come as no surprise that Ktor 2.0 brings proper package names and discoverable modules. To make upgrading to the new version easier, the team has released the Ktor 1.6 to Ktor 2.0.0 migration guide. Additionally, we will automate the migration process to make sure updating is a smooth experience.
Structural Search and Replace provides a powerful way to search for specific code patterns and replace them with others.
The server side of Ktor
Ktor was designed as a multiplatform framework supported on a server (JVM) and client (JVM, Native, JS), and Ktor 2.0 extends its abilities by bringing Native support to the server.
Features are now plugins. Anything in Ktor that used to be called a feature is now called a plugin. You can create the functionality you want using various plugins, including third-party ones.
We’ve simplified the API, and it no longer contains any unnecessary details – just onCall, onCallReceive, and onCallRespond. Please share any feedback you have about this so that we can continue to enhance the API.
Ktor for client
The API is now simpler and more discoverable. Generics are gone, and the body now includes types, which makes it easier to use.
Retries were highly requested, so they now come bundled. With Ktor 2.0, you can say whether a retry is of a specific type or on a specific exception, and you can implement certain delays without having to use any exponential decay functions.
Additionally, Ktor for the client now comes with content negotiation – you can do content negotiation like you would with a server especially in microservices.
Documentation
We didn’t forget the Documentation. It has been rewritten, and all the previous gaps have been filled. Every single sample is up to date and available for download!
Generators and IDE support
There’s a new generator at start.ktor.io that consists of just two simple steps: choosing a name and additional settings, and choosing plugins (that used to be called features), including third-party ones.
And that’s just the beginning.
Spring Native with Kotlin
Sébastien Deleuze shared a comprehensive overview of the new Ahead-of-Time transformations that allow Spring Boot Native applications to have smaller footprints and improved Native compatibility, and he announced some other new features as well.
What is Spring Native?
Spring Native offers Beta support for compiling Spring Boot applications to Native executables with GraalVM, providing a new way to deploy Spring Boot applications that allows them to run exceptionally efficiently.
Kotlin/JVM/Native
The discussion of the Kotlin/JVM target and compiling the bytecode with GraalVM naturally leads us to Kotlin/JVM/Native. It provides the perfect fit because it allows you to go Native while staying in the JVM ecosystem, and the Spring and Kotlin compiler plugin infrastructures are excellent with Native.
Future Kotlin adoption
The next wave of Kotlin market share increases might not come from better language aspects, but instead from the investments into the K2 compiler and the upcoming new compiler frontend, third-party compiler plugins, Compose for Web, and Kotlin/Wasm.
Ahead-of-Time (AOT) transformations
The Spring AOT Maven and Gradle plugins perform powerful build-time transformations on Spring Boot applications to improve efficiency on Native, and potentially on the JVM as well. Spring’s AOT strategy includes bringing Spring Fu efficiency to Spring Boot applications. On this topic, it’s worth noting that AOT mode is mandatory for Native but optional for the JVM.
Hard performance data
Build time is almost instant on the JVM. Native still takes some time, but it will be reduced with the upcoming Native 0.11.
Native already makes container image sizes much smaller than they are in the JVM, and with the upcoming UPX compression, they will be about half as large as they are now.
AOT brings a 10% memory footprint improvement for the JVM. The footprint for Native is already significantly lower, but with 0.11, the memory footprint will be reduced by even more – by up to 20% compared to 0.10.
Startup on Native is almost instant (taking 80 milliseconds tops), and this will be cut in half with Native 0.11
Roadmap
- AOT application context
- GraalVM 21.3 with reflection optimizations
- Java 11 and Java 17 support
- Spring Boot 2.6.0
- UPX compression for container images
The future of Spring Native is first-class Native support in Spring Boot 3.x. This will allow for better compatibility and footprinting via more significant changes in Spring.
Spring is now building a framework for the next decade.
Subscribe to Kotlin Blog updates
