link.zeljko

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