Apparently everybody’s favourite JVM language beat Java in a recent code-smell contest. The Register reported on a paper by Bruno Gois Mateus and Matias Martinez who had carried out an extensive survey of the rate of Kotlin usage in recent open-source Android projects. Well, they’d have to be fairly recent, wouldn’t they. Using the Paprika tool to sniff out anti-patterns, they reached the not so surprising conclusion that the Kotlin code under scrutiny smelled a lot better than your average Android project in Java.
Spring Fu is an experimental Kotlin micro-framework that makes it easy to create lightweight Spring-powered applications with functional APIs instead of annotations. Fu is for functional API, but that’s also a wordplay with the -fu suffix which means skill, the chinese character which means “good luck” and the chinese poetry. Sébastien Deleuze announced this interesting new Micro framework on twitter:
Today, I am proud to announce a new experimental project: Spring Fu. It is a @Kotlin micro-framework that makes it easy to create lightweight Spring-powered applications with functional APIs instead of annotations. We are looking for feedback. https://t.co/R15wJ1gD8Kpic.twitter.com/ScljoPZ8rW
One of the interesting features is that Spring Fu really allows you to develop the full stack using Kotlin by writing your Gradle build file and application code in Kotlin.
Josh Long has put up a great youtube video to get you started with Spring Fu:
The micro part for me is due to minimal reflection usage, no classpath scanning and no annotation processing. While this requires you to be a bit more explicit in the configuration, it boosts startup of you application significantly. For more details make sure to check out the project on github: https://github.com/spring-projects/spring-fu
Last week I was working on a code base which had been partially converted from Java to Kotlin. The converted Java code base was making extensive use of java.util.Optional. The use of Optional might be helpful in situations where you want to be very explicit about the fact that a function or variable might be empty (null), to avoid java.lang.NullPointerExceptions.
Kotlin has many things going for it, with one of the main qualities being its built-in null-safety. This guarantees that properties will always have a non-null value at runtime, greatly reducing the risks of coding errors and NullpointerExceptions. In languages where this isn’t the case — Java, anyone? — the lack of this feature is sometimes (ab)used by the libraries and frameworks we utilize (Spring and its property injection for instance).
This post will cover the way Kotlin deals with properties and their initialization.