Konstantin Pavlov

Spring Boot comes with very neat configuration mechanism. Default application configuration is defined in one configuration file and environment specific setting in separate files. But still, this mechanism is often not used properly resulting in verbose and unmaintainable configurations.

In this post I will show how to build simple data-enriching pipeline using Kotlin coroutines. I will use Channels and Actors abstractions provided by kotlinx-coroutines. In Actors model “actors” are the universal primitives of concurrent computation. In response to a message that it receives, an actor can: make local decisions, create more actors, send more messages, and determine how to respond to the next message received. Actors may modify their own private state, but can only affect each other through messages (avoiding the need for any locks). Let’s start with high-level definition of the pipeline: (👤Producer) -✉️→ 📬(👤Enricher) -✉️→ 📬(👤Updater) RawData RichData Pipeline will have Producer Actor, which will get some raw data from database or some mock data and will send it to pipeline for enrichment. Then Enricher Actor will handle raw data object and add some attributes to it. Finally, Updater Actor will store enriched data to the database. For the sake of simplicity, let’s implement squaring function: we will take integers as raw data and will enrich them by squaring. Let’s define our data model: data class RawData(val value: Int) Enriched data will be represented by data class RichData: data class RichData(val value: Int, val square: Int) Following Actors model, we will use Kotlin Actors to represent processing units in a pipeline and Channels to communicate with Actors. In Kotlin actors are implemented as part of kotlinx-coroutines library: An actor is an entity made up of a combination of a coroutine, the state that is confined and encapsulated into this coroutine, and a channel to communicate with other coroutines.

What happened? # Oracle has changed release and licensing policy for JDK: The JDK still remains completely free for use. The thing that is changing is the availability of updates to specific versions of the JDK. The only free for use in production JDK binary available from Oracle (as of JDK 11) will be the OpenJDK binaries. These will only have public security patch and bug fix updates for six months, until the release of the next version. There is no free LTS release of the JDK from Oracle (for use in production). Users can continue to use any binary of the JDK (the Oracle version or OpenJDK one) indefinitely. They will not, however, continue to get updates to these JDKs once public updates end. Commercial users who want to continue to get security patches and bug fixes for JDK 8 or subsequent LTS releases after public updates have ended will have three options: Purchase a commercial support contract from Oracle. Use a different binary distribution of the OpenJDK, which has security patches and bug fixes backported to it. Create their own binary distribution from the OpenJDK source code and backport updates themselves. How does it encourage agility? # Most of the companies are not willing to purchase commercial support from Oracle. At the same time, they need to get latest security updates. So, what companies have to do –- is to upgrade JDK on production environments more frequently: at least every 6 months. It means, that companies has to re-test and re-deploy their applications at least every 6 months, after each JDK update.