Posts

Showing posts from 2017

Kotlin and Java EE Part Three - Making it Idiomatic

Kotlin and Java EE Part Three - Making it IdiomaticConverting 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 KotlinKotlin and Java EE: Part Two - Having Fun with PluginsAfter briefly revisiting already made changes, I will add some final touches.What We Already DidMany constructs from the previous two parts are already idiomatic Kotlin. Let’s take a look at set definition:privatefinal Set<Class<?>> classes =newHashSet<>(Arrays.asList(KittenRestService.class));As Java does not support a simple construction of Set and some other collections from a list of objects, we have to go to Arrays class to create List (!), and the…

Kotlin and Java EE: Part Two - Having Fun with Plugins

Kotlin and Java EE Part Two - Having Fun with PluginsIn 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 would be automatically populated…

Kotlin and Java EE: Part One - From Java to Kotlin

Kotlin and Java EE: Part One - From Java to KotlinOne 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 avoidedOur 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 GitHub.Making Kotlin classes Java EE frien…