Let's talk about Kotlin!

Yeah! We are part of the Talking Kotlin podcast! In mid december we had a nice little recording session, where two of our meshPeople talked about their experiences during our Kotlin adoption in the meshcloud backend.

While we started with a plain Java Spring Boot application, we have reached about 70% Kotlin code by now. Stefan already highlighted the greatest Kotlin benefits in one of his previous blogposts.
In the podcast Johannes and Stefan talk in detail about their experiences and challenges during the adoption to Kotlin. In this context they also talk about the advantages and requirements of Spring Boot and as an example for this about an implementation of a simple Spring Boot application in Java vs. Kotlin.

You can listen to it here: http://talkingkotlin.com/kotlin-on-the-backend-at-meshcloud/

We hope you enjoy it just as much as we did. Do you have any questions or comments? Feel free to leave a comment.

by Christina Kraus

Kotlin vs. Java Implementation of a Spring Boot application

A good approach for showing the differences between Java and Kotlin is creating an example application. Therefore, I created a simple Spring Boot application. I converted this app to 100% Kotlin. The project can be found on Github. The java branch contains the initial Java application and in the master branch, the converted Kotlin application can be found. Comparing the implementations shows the advantages of Kotlin compared to Java pretty well. I already described some of the benefits you can gain when switching from Java to Kotlin in one of my last blog posts. A list of all advantages, that are also reflected in the example project can be found on the slides I created in combination with the example project.

Some statistics regarding the conversion are already pretty interessting as the following table shows.

Of course, data classes lead to the largest reduction of LoC. But still 21% code reduction without data classes shows, that there is much less boilerplate code you have to write and that can disctract you.

One of my favorite advantages shown in the example project is the usage of a when expression in Kotlin instead of a switch-case statement in Java.

Java:

private double getPlatformCost(Resource resource) {
    double cost;
    switch (resource.getType()) {
        case OPENSTACK:
            cost = 0.03;
        break;
        case CLOUDFOUNDRY:
            cost = 0.02;
        break;
        case KUBERNETES:
            cost = 0.01;
        break;
        default:
        break;
    }
    return resource.durationInHours() * cost;
}

Kotlin:

private fun getPlatformCost(resource: Resource): Double {
    val cost: Double = when (resource.type) {
        ResourceType.OPENSTACK -> 0.03
        ResourceType.CLOUDFOUNDRY -> 0.02
        ResourceType.KUBERNETES -> 0.01
    }
    return resource.durationInHours() * cost
}

By simply checking out both branches of the example project, you can easily compare class by class how much cleaner and more concise the Kotlin code is.

The example can also be used as a reference implementation for a Spring Boot 1.x application with Kotlin. Spring Boot 2.x already supports Kotlin and you can generate a basic application using Kotlin on start.spring.io. When creating a Spring Boot 1.x application with Kotlin, some specialties have to be considered. This example project can be used to see how this all fits together in an actual Spring Boot project.

by Stefan Tomm

Explicitly exposing APIs in Spring Data Rest

In our production system we use Spring Data Rest. We found out that it was too easy to leave a Repository method "exported" by default. We consider this as a security risk because it can be difficult to keep track of all repositories.
Therefore, we developed a new strategy to set the exported value of SDR methods to false to ensure security by default. The currently available detection strategies in SDR only allow to restrict REST repositories on class level. So when a Repository is exported, all of its methods are exported, too. Only by using RestResource(exported = false), you can prevent SDR from exporting a given method.

We created a new strategy to set the exported value of SDR methods to false. The currently available detection strategies in SDR only allow to restrict REST repositories on class level. So when a Repository is exported, all of its methods are exported, too. Only by using RestResource(exported = false), you can prevent SDR from exporting a given method.

We identified in our project, that there is a certain security risk in that case. Developers are not always aware of all the methods that are automatically exported via REST by the application. By simply adding new Repositories and just wanting a findAll()-method to be publicly available, even save and delete methods are exported by default. As most applications want to apply security especially on the write methods, an additional "pessimistic" strategy can be useful in Spring. That way you can still profit from all the benefits SDR provides, but you can be sure, that only methods you explicitly added and annotated with @RestResource are exported.

The following example shows how the exporting with the new strategy should work:

@RepositoryRestResource
interface PersonRepository extends Repository<Person, Long> {
@RestResource
Iterable findAll();

Iterable findByFirstname(@Param("firstname") String firstname);

}

In that case, only the findAll() method is exported via REST. The findByFirstName and all CRUD methods like save or delete are not exported via REST by default. They have to be added explictily and annotated with @RestResource if they shall be exported via REST.

We sent our solution as pull request to Spring Data REST. We got feedback and they decide that they would integrate our new feature (https://jira.spring.io/browse/DATAREST-1176 ).

by Tobias Weiß

Tips for using Kotlin with Spring Boot 1.x

Even though full Kotlin support is only available starting with Spring 5, writing Spring 4 applications in Kotlin is already working pretty well. You just have to know some of the specialties of this combination. At meshcloud, we have been working with Kotlin and Spring Boot 1.5, which is based on Spring 4, successfully for several months. In this post, we want to share some guidance about small stumbling blocks we encountered and how we got around them.

1. Spring components have to be open

All classes defined in Kotlin are final by default. That means you cannot overwrite the methods in child classes. As Spring uses a proxy approach to provide its components, all public methods of Spring components must be overridable in child classes. The explicit solution to this is pretty simple. You have to mark your class and all public methods with the keyword open.

open class PersonController {
  @GetMapping
  open fun findAll() {
    …
  }
}

A less obvious, but definitely much more comfortable way is using the Kotlin-Spring compiler plugin. It makes all Spring components open by default. As exceptions caused by missing open declarations can be very confusing and not indicate the actual problem, we definitely recommend using the plugin, as it will protect you from frustrating error analysis. IntelliJ detects the presence of this plugin in your gradle or maven configuration and will automatically highlight any redundant open modifiers and missing final declarations, for example for methods called from constructors.

2. Handling Autowired properties

If you are using property injection, auto conversion to Kotlin by IntelliJ results in converting these properties to nullable values.

open class PersonController {
  @Autowired
  private var personRepository: PersonRepository? = null
}

In order to take advantage of Kotlins support for explicit nullability, there are two solutions for refactoring this code.

1. Use lateinit vars

private lateinit var personRepository: PersonRepository

This allows making the autowired property not nullable. It tells the compiler, that the property will be set before actually accessing it. The Kotlin compiler will emit code that checks that the variable is initialized by the time it gets used and if it isn't, it throws an exception accordingly.

2. Use constructor injection

open class PersonController(
  private val personRepository: PersonRepository
){ ... }

This is our preferred solution, because it allows us to define the property as immutable, and we don't need the @Autowired annotation anymore. If the injection fails, an exception occurs during object creation and not somewhere later in the code.

Even fields annotated with @Value for configuration data can be injected in the constructor. One thing to consider here is that Kotlin uses the $ sign for string templates. Therefore the $ in the @Value annotation needs to be escaped explicitly.

open class PersonController(
  @Value(“\${mail.host}”)
  private val host: String
){ ... }

3. HATEOAS ControllerLinkBuilder.methodOn and null parameters

At least with Spring 4, using the ControllerLinkBuilder has some downsides. When the controller method has parameters like a principal or an @RequestBody, you usually submit null in the methodOn call. Let’s say you at first convert the Controller to Kotlin:

open class PersonController {
  @GetMapping
  open fun findAllOwnedByCurrentUser(principal: Principal) {
    …
  }
}

In the Controller, we want our parameters to be not nullable. As long as the class using the ControllerLinkBuilder is written in Java, everything works fine and null can be submitted, because the method is not actually called. So this would be a possible solution.

As we currently want to convert all our code to Kotlin, we use the following solution for now. We actually define the parameters as nullable in the controller and enforce their existence at the beginning of the method (thanks to Kotlin's smart casts!).

open class PersonController {
  @GetMapping
  open fun findAllOwnedByCurrentUser(principal: Principal) {
    principal!!
    ...
  }
}

This solution allows us to use the parameter like a not nullable parameter within the function. As soon as a better solution is available, we can easily remove this check.

As Spring 5 has native Kotlin support, we expect this issue to be solved when switching to it.

4. Default Constructor for JPA entities

Eventhough this is a JPA related topic, it is something worth mentioning in the context of Spring Boot, as many of those applications use JPA. JPA always requires a default constructor on entities. A @PersistenceConstructor exists, that should generate this constructor for you.

@Entity
data class Person @PersistenceConstructor constructor (
  val firstName: String,
  val lastName: String
)

Sadly, this didn't work for us in all cases. We switched to the solution of defining default values for all properties of an entity. That way a default constructor is available for JPA:

@Entity
open class Person (
  val firstName: String = "",
  val lastName: String = ""
)

By now there is also a Kotlin-JPA compiler plugin available which makes the default constructor available for JPA automatically. With this approach simple classes and data classes can be used for entities.

by Stefan Tomm

JSR-363 Units of Measurement API in Practice - JSON Serialization

In the last post we looked at how to persist JSR-363 types like Quantity<q> with Spring Data using a pair of converters to serialize a Quantity to string and back. In this post we will look at how to serialize Quantity to JSON using a similar trick. This allows us to use Quantities and Units in a REST API.

The JacksonQuantityModule

Jackson offers the module SPI to allow consumers to register various hooks for JSON serialization and deserialization. For example, the Jackson Kotlin module uses this mechanism to help Jackson better serialize Kotlin specific types like Pair<T, U>.

So here's our JacksonQuantityModule:

@Suppress("unused")
class JacksonQuantityModule : SimpleModule(PackageVersion.VERSION) {
  companion object {
    private val serialVersionUID = 1L
  }

  override fun setupModule(context: SetupContext) {
    addSerializer(Quantity::class.java, QuantitySerializer)
    addDeserializer(Quantity::class.java, QuantityDeserializer)

    super.setupModule(context)

  }

  object QuantitySerializer : JsonSerializer<Quantity<*>>() {
    override fun handledType()API: Class<Quantity<*>> {
      return Quantity::class.java
    }

    override fun serialize(value: Quantity<*>, gen: JsonGenerator, serializers: SerializerProvider?) {
      val formatted = QuantityFormatting.QuantityToStringConverter.convert(value)
      gen.writeString(formatted)
    }
  }

  object QuantityDeserializer : JsonDeserializer<Quantity<*>>() {
    override fun handledType(): Class<Quantity<*>> {
      return Quantity::class.java
    }

    override fun deserialize(p: JsonParser, ctxt: DeserializationContext?): Quantity<*>? {
      val source = p.valueAsString
      return QuantityFormatting.StringToQuantityConverter.convert(source)
    }
  }
}

If you want to auto-register this module with Jackson through the SPI mechanism, just add a text file as a resource at META-INF/services/com.fasterxml.jackson.databind.Module with the fully qualified classname of our module as its content:

my.package.JacksonQuantityModule

Unit Tests for JacksonQuantityModule

Let's add some quick unit tests for this module to verify SPI auto-registration and the module implementation work as expected:

val sut = ObjectMapper().apply {
  findAndRegisterModules()
}

@Test
fun handlesQuantities() {
  verify(ObjectWithQuantity(1.mega.byte), """{"q":"1 MBy"}""")
}

@Test
fun handlesNullQuantities() {
  verify(ObjectWithQuantity(null), """{"q":null}""")
}

private inline fun verify(obj: T, expectedJson: String) {
  val json = sut.writeValueAsString(obj)
  Assert.assertEquals(expectedJson, json)

  val result = sut.readValue(json)
  Assert.assertEquals(obj, result)
}

Both tests pass, mission accomplished.

by Johannes Rudolph

JSR-363 Units of Measurement API in Practice - Binary Prefixes

When working with units of measurement it's often useful to apply a prefix to capture the order of magnitude. The SI unit system has a standard set of prefixes based on powers of 10, e.g. kilo: 10³ or mega: 10⁶. For quantities of information like bits and bytes, it\'s however often useful to have prefixes based on powers of 2 like MeBi: 2²⁰. These are also called binary prefixes.

The tec.uom.se library introduced eralier in this series of blog-posts has a class BinaryPrefix, but it only offers methods for unit conversion. Let\'s build a short helper class and build a nice fluent API in Kotlin so that we can write e.g. 10.mebi.byte for 10 MiB.

object QuantityFormatting {
  private val unitFormatter = UcumFormatWithBinaryPrefixSupport()

  private val numberFormatter = NumberFormat.getInstance(Locale.ROOT)
  private val separator = " "

  object QuantityToStringConverter : Converter<Quantity<*>, String> {
    override fun convert(source: Quantity<*>): String {
      val s = source.toWildcard()
      val formattedUnit = unitFormatter.format(s.unit)
      val formattedValue = numberFormatter.format(s.value)

      return "$formattedValue$separator$formattedUnit"
    }
  }

  object StringToQuantityConverter : Converter<String, Quantity<*>> {
    override fun convert(source: String): Quantity<*> {
      val (formattedValue, formattedUnit) = source.split(separator, limit = 2)

      val parsedUnit: Unit = unitFormatter.parse(formattedUnit).toWildcard()
      val parsedValue = numberFormatter.parse(formattedValue)

      return Quantities.getQuantity(parsedValue, parsedUnit)
    }
  }

  class UcumFormatWithBinaryPrefixSupport(val base: UCUMFormat = UCUMFormat.getInstance(UCUMFormat.Variant.CASE_SENSITIVE))
    : UnitFormat by base {

    override fun format(unit: Unit<*>): String {
      val baseResult = base.format(unit)
      val split = baseResult.split(".")

      if (split.size == 1) {
        return baseResult
      }

      val (symbol, converter) = split
      return when (converter) {
        BinaryPrefix.YOBI.converterFormat -> "${BinaryPrefix.YOBI.symbol}$symbol"
        BinaryPrefix.ZEBI.converterFormat -> "${BinaryPrefix.ZEBI.symbol}$symbol"
        BinaryPrefix.EXBI.converterFormat -> "${BinaryPrefix.EXBI.symbol}$symbol"
        BinaryPrefix.PEBI.converterFormat -> "${BinaryPrefix.PEBI.symbol}$symbol"
        BinaryPrefix.TEBI.converterFormat -> "${BinaryPrefix.TEBI.symbol}$symbol"
        BinaryPrefix.GIBI.converterFormat -> "${BinaryPrefix.GIBI.symbol}$symbol"
        BinaryPrefix.MEBI.converterFormat -> "${BinaryPrefix.MEBI.symbol}$symbol"
        BinaryPrefix.KIBI.converterFormat -> "${BinaryPrefix.KIBI.symbol}$symbol"
        else -> baseResult
      }
    }

    override fun format(unit: Unit<*>, appendable: Appendable): Appendable {
      return appendable.append(format(unit))
    }

    override fun parse(csq: CharSequence): Unit<*> {
// note: all binary prefixes have two chars
      val prefixLength = 2
      val (prefix, originalUnit) = when {
        csq.length >= prefixLength -> Pair(csq.substring(0, prefixLength), csq.substring(prefixLength))
        else -> Pair(null, csq)
      }

      return when (prefix) {
        BinaryPrefix.YOBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.YOBI.converter)
        BinaryPrefix.ZEBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.ZEBI.converter)
        BinaryPrefix.EXBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.EXBI.converter)
        BinaryPrefix.PEBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.PEBI.converter)
        BinaryPrefix.TEBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.TEBI.converter)
        BinaryPrefix.GIBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.GIBI.converter)
        BinaryPrefix.MEBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.MEBI.converter)
        BinaryPrefix.KIBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.KIBI.converter)
        else -> base.parse(csq)
      }
    }
  }
}

Another missing feature is support for string serialization of binary-prefixed units. Unfortunately, the UCUMFormatter of the UOM library is not extensible, so we need to add a simple pre/post-processing step to our formatters from the last episode.

object QuantityFormatting {
  private val unitFormatter = UcumFormatWithBinaryPrefixSupport()

  private val numberFormatter = NumberFormat.getInstance(Locale.ROOT)
  private val separator = " "

  object QuantityToStringConverter : Converter<Quantity<*>, String> {
    override fun convert(source: Quantity<*>): String {
      val s = source.toWildcard()
      val formattedUnit = unitFormatter.format(s.unit)
      val formattedValue = numberFormatter.format(s.value)

      return "$formattedValue$separator$formattedUnit"
    }
  }

  object StringToQuantityConverter : Converter<String, Quantity<*>> {
    override fun convert(source: String): Quantity<*> {
      val (formattedValue, formattedUnit) = source.split(separator, limit = 2)

      val parsedUnit: Unit = unitFormatter.parse(formattedUnit).toWildcard()
      val parsedValue = numberFormatter.parse(formattedValue)

      return Quantities.getQuantity(parsedValue, parsedUnit)
    }
  }

  class UcumFormatWithBinaryPrefixSupport(val base: UCUMFormat = UCUMFormat.getInstance(UCUMFormat.Variant.CASE_SENSITIVE))
    : UnitFormat by base {

    override fun format(unit: Unit<*>): String {
      val baseResult = base.format(unit)
      val split = baseResult.split(".")

      if (split.size == 1) {
        return baseResult
      }

      val (symbol, converter) = split
      return when (converter) {
        BinaryPrefix.YOBI.converterFormat -> "${BinaryPrefix.YOBI.symbol}$symbol"
        BinaryPrefix.ZEBI.converterFormat -> "${BinaryPrefix.ZEBI.symbol}$symbol"
        BinaryPrefix.EXBI.converterFormat -> "${BinaryPrefix.EXBI.symbol}$symbol"
        BinaryPrefix.PEBI.converterFormat -> "${BinaryPrefix.PEBI.symbol}$symbol"
        BinaryPrefix.TEBI.converterFormat -> "${BinaryPrefix.TEBI.symbol}$symbol"
        BinaryPrefix.GIBI.converterFormat -> "${BinaryPrefix.GIBI.symbol}$symbol"
        BinaryPrefix.MEBI.converterFormat -> "${BinaryPrefix.MEBI.symbol}$symbol"
        BinaryPrefix.KIBI.converterFormat -> "${BinaryPrefix.KIBI.symbol}$symbol"
        else -> baseResult
      }
    }

    override fun format(unit: Unit<*>, appendable: Appendable): Appendable {
      return appendable.append(format(unit))
    }

    override fun parse(csq: CharSequence): Unit<*> {
// note: all binary prefixes have two chars
      val prefixLength = 2
      val (prefix, originalUnit) = when {
        csq.length >= prefixLength -> Pair(csq.substring(0, prefixLength), csq.substring(prefixLength))
        else -> Pair(null, csq)
      }

      return when (prefix) {
        BinaryPrefix.YOBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.YOBI.converter)
        BinaryPrefix.ZEBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.ZEBI.converter)
        BinaryPrefix.EXBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.EXBI.converter)
        BinaryPrefix.PEBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.PEBI.converter)
        BinaryPrefix.TEBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.TEBI.converter)
        BinaryPrefix.GIBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.GIBI.converter)
        BinaryPrefix.MEBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.MEBI.converter)
        BinaryPrefix.KIBI.symbol -> base.parse(originalUnit).transform(BinaryPrefix.KIBI.converter)
        else -> base.parse(csq)
      }
    }
  }
}

With that, we can make the following test pass:

@Test
fun serializingBinaryPrefixedUnits(){
  val sut = 1.mebi.byte
  val serialized = QuantityFormatting.QuantityToStringConverter.convert(sut)

  Assert.assertEquals("1 MiBy", serialized)

  val deserialized = QuantityFormatting.StringToQuantityConverter.convert(serialized)
  Assert.assertEquals(sut, deserialized)
}

by Johannes Rudolph