Sébastien Deleuze

Sébastien Deleuze

Spring Framework committer

Lyon, France

Blog Posts by Sébastien Deleuze

The path towards Spring Boot native applications

I would like to use the opportunity of our Spring GraalVM Native 0.7.0 release to give you a status update about our work on Spring Boot native images.


Native image provides a way to build and run Spring Boot applications with different characteristics than a regular JVM deployment:

  • The output is a native executable that contains your application with a subset of the JDK and the dependencies required to run it.

  • In practice the executable would likely be shipped in an highly optimized container image (FROM scratch Docker image is supported) with reduced surface attack which is good fit with Kubernetes.

  • Startup time is almost instant and peak performance is available immediately, allowing support for scale-to-zero (serverless) applications including for regular Spring Boot web applications.

  • Memory consumption is reduced, which is a good fit for systems split into multiple microservices.

As you would expect, native images are not a free lunch and those interesting capabilities come with a few drawbacks:

  • GraalVM native is a young platform which is far less mature than the JVM.

  • This new flavor of Java is not yet well supported and tested by JVM libraries.

  • It requires initialization, resources, reflection and proxy explicit configuration.

  • Build time is very long and build memory consumption is high.

  • Lower throughput and higher latency (more details ).

Obviously native image is a moving target and some of those characteristics are likely to evolve in the future. The Spring team currently collaborates actively with the GraalVM team in order to ensure Spring and more globally the JVM ecosystem integrated via Spring Boot works well when compiled as native images. This effort includes fixes and new features in GraalVM native, changes to Spring itself, but also additional work to improve testability and maintainability with this GraalVM native platform.

It is also worth noticing that the scope of native images is now wider than GraalVM since Mark Reinhold has recently announced Project Leyden, an effort to standardize native images at Java platform level.


Spring Fu 0.3.0 and beyond

I am happy to announce that Spring Fu 0.3.0 is available. As a reminder, Spring Fu is an incubator for Spring Boot programmatic configuration using DSLs in order to configure it explicitly with code in a declarative way, achieving great discoverability thanks to auto-complete.

JaFu is back!

This new milestone brings back JaFu (the Java DSL) in addition to KoFu (the Kotlin DSL). JaFu was removed in 0.1.0 because at that point, I had not the bandwidth to support both Java and Kotlin DSLs, and in term of API I was not sure that the Java variant was attractive enough to justify such effort, but I have changed my mind for various reasons:

  • I received a lot of requests to bring it back

  • Java as a language is moving faster

  • Getting more control on how configuration is applied is interesting for Java developers as well as Kotlin ones

  • Functional approach is naturally very efficient on the JVM and a good fit with GraalVM native images

  • 2 great new contributors have join the team: Audrey Neveu with a focus on KoFu and Arjen Poutsma with a focus on JaFu. Welcome to them!


Going Reactive with Spring, Coroutines and Kotlin Flow

Since we announced Spring Framework official support for Kotlin in January 2017, a lot of things happened. Kotlin was announced as an official Android development language at Google I/O 2017, we continued to improve the Kotlin support across Spring portfolio and Kotlin itself has continued to evolve with key new features like coroutines.

I would like to take the opportunity of the first milestone of Spring Framework 5.2 to give a status overview of where we are when it comes to Spring and Kotlin. And I will make my best to focus on concrete improvements since I believe Spring and Kotlin share the same pragmatic mindset.


The evolution of Spring Fu

I take the opportunity of a short stop between SpringOne platform where I gave the first talk about Spring Fu and Kotlinconf to give an overview of the evolution of this project, summarize the current status and share what could be the next steps.

Early June, I announced a new experimental project named Spring Fu, with the goal to experiment on a new kind of API to configure Spring applications using Kotlin DSL and functional configuration.


New tutorial about Spring Boot and Kotlin

For 2 years, we have introduced Kotlin support in Spring projects (Framework, Boot, Data) and published various blog posts, sample projects, slides and documentation. Today, we are publishing an opinionated tutorial intended to summarize in a single place how to build a Spring Boot web application in Kotlin leveraging these features and following best practices:

Topics covered are:

  • How to create a Spring Boot 2 project in Kotlin
  • Understanding the build configuration
  • Testing with JUnit 5: integration tests, @WebMvcTest + mocking
  • Persistence with JPA and data classes
  • Creating your own extensions
  • Rendering web pages with Mustache
  • HTTP API with @RestController
  • Configuration properties

Spring Framework 5 Kotlin APIs, the functional way

Update: see also Spring Fu experimental project.

Since our original announcement (very well received by the community!) of official Kotlin support in Spring Framework 5, we have continued to work towards even stronger Kotlin support in conjunction with recent refinements in Spring WebFlux.

In order to demonstrate these features, and how they could be used together, I have created a new spring-kotlin-functional demo application which is a standalone Spring WebFlux application, developed in Kotlin, with Mustache template rendering, JSON REST webservices and Server-Sent Events streaming capabilities. Don’t hesitate to send us feedbacks and proposals before Spring Framework 5 release expected in September.


Reactor Kotlin Extensions 1.0.0.M1 released

Update: Kotlin is now natively supported by reactor-core and reactor-test without requiring any additional extensions.

I am excited to announce the release of the first milestone of Reactor Kotlin Extensions, which provides Kotlin extensions for Reactor API.

It provides support for Kotlin types like KClass, takes advantage of Kotlin reified type parameters and provide various extensions to allow more expressive code. You can see bellow a quick comparaison of Reactor with Java versus Reactor with Kotlin + extensions.


Introducing Kotlin support in Spring Framework 5.0

Update: a comprehensive Spring Boot + Kotlin tutorial is now available.

Following the Kotlin support on we introduced a few months ago, we have continued to work to ensure that Spring and Kotlin play well together. One of the key strengths of Kotlin is that it provides a very good interoperability with libraries written in Java. But there are ways to go even further and allow writing fully idiomatic Kotlin code when developing your next Spring application. In addition to Spring Framework support for Java 8 that Kotlin applications can leverage like functional web or bean registration APIs, there are additional Kotlin dedicated features that should allow you to reach a new level of productivity.


Understanding Reactive types

Following previous Reactive Spring and Reactor Core 3.0 blog posts, I would like to explain why Reactive types are useful and how they compare to other asynchronous types, based on what we have learned while working on the Spring Framework 5 upcoming Reactive support.

Why using Reactive types?

Reactive types are not intended to allow you to process your requests or data faster, in fact they will introduce a small overhead compared to regular blocking processing. Their strength lies in their capacity to serve more request concurrently, and to handle operations with latency, such as requesting data from a remote server, more efficiently. They allow you to provide a better quality of service and a predictable capacity planning by dealing natively with time and latency without consuming more resources. Unlike traditional processing that blocks the current thread while waiting a result, a Reactive API that waits costs nothing, requests only the amount of data it is able to process and bring new capabilities since it deals with stream of data, not only with individual elements one by one.


A Geospatial Messenger with Kotlin, Spring Boot and PostgreSQL

Following my first Kotlin blog post, today I want introduce the new Spring Boot + Kotlin application I have developed for my upcoming Spring I/O 2016 conference talk “Developing Geospatial Web Services with Kotlin and Spring Boot”.

Dealing with native database functionalities

One of the goal of this application is to see how to take advantage of native database functionalities like we do in NoSQL world. Here we want to use Geospatial support provided by PostGIS, the spatial database extender for PostgreSQL. Native JSON support could also be a good use case.