link.zeljko

Intention of Kotlin's "also apply let run with" One of the things that puzzled me when I started with Kotlin was why are there so many similar functions which call lambda on some objects and returns a value. After many lines of code and many lines of user group discussions, I found out that they represent a small DSL for easier monadic-style coding. Explanation of this DSL and intent of each function is missing from the Kotlin documentation, so this article will hopefully shed some light on it. There is also a short style guide on GitHub. also With this function, you say “also do this with the object”. I often use it to add debugging to the call chains or to do some additional processing: kittenRest . let { KittenEntity ( it . name , it . cuteness ) } . also { println ( it . name ) } . also { kittenCollection += it } . let { it . id } also passes object as parameter and returns the same object (not the result o

Kotlin and Java EE Part Three - Making it Idiomatic Converting Java EE application to Kotlin started with the battle with the framework, where we successfully outmaneuvered all the obstacles presented by sometimes archaic standards. In the process, the code was enriched with modern, Kotlin-specific constructs making it concise and safer. If you did not read the previous two parts of the series, you can find them here: Kotlin and Java EE: Part One - From Java to Kotlin Kotlin and Java EE: Part Two - Having Fun with Plugins After briefly revisiting already made changes, I will add some final touches. What We Already Did Many constructs from the previous two parts are already idiomatic Kotlin. Let’s take a look at set definition: private final Set < Class < ? >> classes = new HashSet < > ( Arrays . asList ( KittenRestService . class ) ) ; As Java does not support a simple construction of Set and some other collections from a li

Kotlin and Java EE Part Two - Having Fun with Plugins In the previous installment of the series, we saw that, while it is easy to convert Java to Kotlin, a lot of additional work must be done to make Kotlin Java EE compatible. It is manual work and it is error-prone, mostly due to friction between JavaBeans specification and Kotlin. JavaBeans is an old standard, literary from the last millennium. It was conceived to make component manipulation in RAD visual editors possible. For example, the user would drag and drop text field from the toolbar to the form, and then he would set the text, color, and other property. The component had to be constructed in uninitialized state and configured step-by-step. In a non-GUI world, this concept has many drawbacks: component does not know when the configuration is finished, and the user does not know which properties must be set to complete the configuration. With dependency injection (DI) frameworks, such properties woul

Kotlin and Java EE: Part One - From Java to Kotlin One of the main strengths of Kotlin is good Java integration. As it is fairly easy to convert Java to Kotlin, it seems that making Java EE applications in Kotlin should be a no-brainer. However, there are some subtle differences between the two that make conversion tricky: While most frameworks require non-final classes, Kotlin classes are final. Injection will introduce a lot of unnecessary null checks. Both of these and mandatory parameterless constructors will ruin attempts to write functional-style code. Java EE and Kotlin are not really best friends unless you make them to. Luckily, all those issues could be avoided Our target for conversion is a simple Java WAR that can store and retrieve records from the database over REST interface. To get started, pull the fables-kotlin repo from GitHub. The project is in the jee/java directory. If you like to run and test it, check the instructions on the GitH