Kotlin as a Language for the Spring Ecosystem

2017 was a remarkable year for Kotlin. In May, Google announced the language as an officially supported development language for Android at I/O, in September Spring Framework 5.0 was released with dedicated Kotlin support, and just a few weeks ago Kotlin 1.2 was published. For us as Java and Spring developers, this raises an obvious question: Is Kotlin worth looking into beyond the Android world?

Why Kotlin Is Interesting for Spring Developers

Kotlin is a statically typed programming language developed by JetBrains that runs entirely on the JVM. The crucial point for existing Java projects: Kotlin is 100 percent interoperable with Java. This means you can introduce Kotlin code into an existing Java project without having to rewrite everything. Existing Java libraries, Spring annotations, and the entire ecosystem continue to work seamlessly.

The language was designed with the goal of addressing Java's well-known weaknesses -- without sacrificing runtime performance. In day-to-day work, this shows up in three main areas: null safety, significantly less boilerplate code, and more expressive language constructs.

Null Safety: No More NullPointerExceptions

One of the greatest advantages of Kotlin is the type system, which distinguishes between nullable and non-nullable types. In Java, every object reference is potentially null, which has led to the notorious NullPointerException errors for decades. Kotlin solves this problem at the language level.

A type in Kotlin is non-nullable by default. If you want to explicitly allow null, you must mark the type with a question mark:

var name: String = "Kotlin"    // Cannot be null
var title: String? = null      // Nullable, explicitly marked

// Safe access with the ?. operator
val length = title?.length     // Returns null instead of NPE

The compiler enforces that nullable types are checked before access. This eliminates an entire class of errors at compile time -- a tremendous gain for code quality.

Data Classes: Less Boilerplate, More Clarity

A classic example of the difference in expressiveness is data classes. In Java projects with Spring, we all know the typical DTOs and entities with getters, setters, equals(), hashCode(), and toString(). The comparison speaks for itself.

Java:

@Entity
public class Customer {

    @Id
    @GeneratedValue(strategy = GenerationType.IDENTITY)
    private Long id;
    private String firstName;
    private String lastName;
    private String email;

    public Customer() {}

    public Customer(Long id, String firstName, String lastName, String email) {
        this.id = id;
        this.firstName = firstName;
        this.lastName = lastName;
        this.email = email;
    }

    public Long getId() { return id; }
    public void setId(Long id) { this.id = id; }
    public String getFirstName() { return firstName; }
    public void setFirstName(String firstName) { this.firstName = firstName; }
    public String getLastName() { return lastName; }
    public void setLastName(String lastName) { this.lastName = lastName; }
    public String getEmail() { return email; }
    public void setEmail(String email) { this.email = email; }

    @Override
    public boolean equals(Object o) { /* ... */ }

    @Override
    public int hashCode() { /* ... */ }

    @Override
    public String toString() { /* ... */ }
}

Kotlin:

@Entity
data class Customer(
    @Id @GeneratedValue(strategy = GenerationType.IDENTITY)
    val id: Long? = null,
    val firstName: String,
    val lastName: String,
    val email: String
)

The Kotlin example automatically generates equals(), hashCode(), toString(), and a copy() function. Around 40 lines of Java become 7 lines of Kotlin -- with identical functionality. This is not a toy example: in a typical Spring project with dozens of DTOs, this difference adds up significantly.

Extension Functions and Spring

Extension functions allow you to add new methods to existing classes without modifying them or inheriting from them. This fits perfectly with the Spring ecosystem, where you frequently work with framework classes that you don't control yourself.

// An extension function for RestTemplate
fun RestTemplate.getForEntity(url: String): ResponseEntity<String> =
    this.getForEntity(url, String::class.java)

// Usage
val response = restTemplate.getForEntity("https://api.example.com/data")

Spring Framework 5.0 uses this concept itself and ships Kotlin extensions, for instance for RestOperations, BeanDefinitionDsl, or the new functional router DSL for WebFlux.

Spring Framework 5.0 and Kotlin Support

With Spring Framework 5.0, released in September 2017, Pivotal invested significantly in Kotlin. The key highlights:

• Null Safety across the entire API: Spring 5.0 is fully annotated with null-safety annotations that Kotlin understands and evaluates at compile time.
• Kotlin Extensions: Official extension functions for core Spring APIs reduce boilerplate and make the code more idiomatic.
• Functional Bean Registration: With BeanDefinitionDsl, beans can be registered in a type-safe DSL -- without XML and without reflection.
• WebFlux Router DSL: For reactive web applications, Spring offers a Kotlin DSL that defines routing functionally and expressively.

Spring Boot 2.0, currently in its milestone phase, will also treat Kotlin as a first-class supported language. The Spring Initializr at start.spring.io already offers the option to generate a project directly with Kotlin.

A Look at Coroutines

Kotlin 1.1 introduced coroutines, a concept that greatly simplifies asynchronous programming. Instead of nested callbacks or complex reactive streams chains, asynchronous code can be written sequentially. In Kotlin 1.2, coroutines are still marked as an experimental feature but already show great potential.

This is particularly relevant for the Spring ecosystem because Spring 5.0 with WebFlux heavily emphasizes reactive programming. In the future, coroutines could offer a more elegant alternative to Mono and Flux for writing non-blocking code that still remains readable. Development is still in its early stages here, but the direction is right.

Where Do We Stand Today?

Despite all the enthusiasm for the language, we should be honest: Kotlin in the backend is still a comparatively young topic. Most Spring projects in production run on Java, tooling support is excellent in IntelliJ IDEA but still has room for improvement in other IDEs. Documentation and community resources for Kotlin in the Spring context are also not yet as comprehensive as for Java.

Some points to consider:

• Learning Curve: For experienced Java developers, getting started with Kotlin is relatively fast. However, the syntax is different enough that you should consciously set aside time for learning.
• Team Size and Onboarding: In larger teams, it must be ensured that all developers are familiar with Kotlin. A mix of Java and Kotlin in the same project is technically possible but increases complexity.
• Compile Times: The Kotlin compiler is currently still somewhat slower than the Java compiler. This can be noticeable in large projects.
• Libraries and Frameworks: Java interoperability works very well, though you occasionally encounter edge cases, such as with annotation processing or certain reflection patterns.

Conclusion

Kotlin is a mature, pragmatic language that addresses many of Java's weaknesses without abandoning the proven ecosystem. With dedicated support in Spring Framework 5.0 and the upcoming Spring Boot 2.0, the foundation for productive backend use has been laid.

For new projects, it is worth seriously considering Kotlin. For existing Java projects, the interoperability offers the possibility to introduce Kotlin gradually -- for example, in new modules or services.

At encircle360, we will be using Kotlin in selected projects in the coming months and sharing our experiences here on the blog. The language has the potential to fundamentally change the way we develop Spring applications.