I’ve mentioned I used Kotlin to implement a Spring Boot service, here are the bits and pieces needed to make this work. To briefly recap, I had to quickly implemented a service as a proof of concept so went with Kotlin’s Spring Boot integration. It proved to be really easy and as I’ve continued work with the service I’ve been more and more happy the choice.
The Build Bits
I use gradle as the build tool, so lets start with whats needed there.
There’s a lot required, yes, but no particular magic. To make Spring Boot work you need the collection of plugins and dependencies above. Some of these are a little creepy, in particular the kotlin-allopen dependency used to circumvent some of Kotlin’s clean code features to allow for Spring Boot’s inelegant hijinks.
What does this get you? With that build.gradle you’ll be able to develop in Kotlin, use Spring annotations, and run familiar build tasks like gradle bootRun. Additionally, gradle bootRepackage will create a single jar file, including all the Kotlin dependencies, that lets you run the service with java -jar as expected.
Heres my gradle.properties with the versions I used as an up to date and compatible suite:
The Noteworthy Code
The Application class in Kotlin:
Very straight forward. With that in place you’ve now got the best of both worlds. You can write all your code in Kotlin, but annotate it with Spring annotations, for example a For example, a controller might look like:
Sometimes Spring Boot seems like a DNA virus, getting into everything and fundamentally corrupting it. But there it is front and center, widely adopted. I’m not a fan but I’ve used it often when employers asked or when I had to spit out a quick proof of concept.
Last week I had to write a custom status service at work, we needed a quick visual map of the health of the environments for a dashboard. The requirements were simple but didn’t easily work with any existing tool I found out there. So I hacked a Spring Boot service to do what we needed.
But, I decided to add a spoonful of sugar, and implemented it with Kotlin’s Spring Boot support. And wow did the medicine go down smooth. It was actually fun to write, the Spring Boot support was well done, and I ended up with a full fledged Spring Boot service, implemented with fairly idiomatic Kotlin. Nice. I’ll follow up here in another post with notes on the implementation – but just wanted to say – this was a win.
I’ve started seeing articles about Java 11, and my reaction is really?! I’m working mostly in version 8. I’ve done proof of concept work in 9’s new features like modules. I’m building mostly with 10 because the general wisdom is jump to 10 since it’s out. Now I’m seeing traffic on 11.
All that said, it’s common for candidates I interview to be unfamiliar with key additions in 7 let alone 8.
This is just ridiculous. I’m going back to my Kotlin.
Answer: When it’s inlined. Or at least sort of.
I encountered a “list” interface as follows:
Not much of a list right? I wanted to traverse the list and when one of the Nodes met some criteria return it. As an example:
That worked. But I thought I could do it more idiomatically so I tried:
Obvious fail! I mean at first glance it kinda looks right but the return from inside the lambda can’t work! Or can it? It can if you add inline to the function.
Because then the lambda stops being a lambda it’s just an inline block and the return works fine.
How do I Feel About This?
It’s cool, but sort of confusing too. I’m not sure if I’m happy that when I use a lambda I can’t be sure how it will behave unless I look at the code I’m passing it too. So yeah… it’s good and bad I guess.
Kotlin has definitely gotten under my skin, I’ve really taken to the language. It’s a robust language that improves my code consistently, making it cleaner and easier to read. The syntax is clean, mostly avoiding syntactic saccharin, and incorporating OO and functional paradigms harmoniously. Higher order functions are done well incorporating closures beautifully. Performance seems good. Build times are quick. A lot of bad memories of the early days of Scala are contrasted by my Kotlin experience.
The One Soft Spot
Generally I’ve found the tool chain in good shape, but as I consider advocating adoption for larger projects I’ve one concern: code coverage. When you’re working with a large project that should have a longer life, code quality is important. You can race through early sprints, delivering a slew of features, and feeling really positive. But if your code is sloppy, your tests lacking, velocity will start to slow and you’ll find you’re spending most of your effort dealing with mess as opposed to making new progress.
You can avoid this by employing a unicorn team of only responsible rock stars. I’ve been on that team once or twice. But, more likely, you’ve got a mixed bag of people, and you need to develop quality. A good language is a good start, but to improve over time you need to be able to continuously evaluate your work and learn from it. Code coverage tools can really help there.
Kotlin has partial JaCoCo and Sonar support. It works in Codacy. But, hopefully those or tools similar will improve because I think Kotlin is awesome and want to be able to advocate it even to the uninitiated.
I’ve been tinkering with Kotlin and JavaFX and the result was a Java jar file that spins up a user interface. OS X will double click open a jar, but I wanted a normal app. I looked around and found App Maker, which did a decent job, but processing the jar manually each build got annoying fast. Looking at the info out there, and what App Maker did, it seemed like I ought to be able to get gradle to do the same without too much pain. I did.
The Simplest App Possible
So, from documentation, and investigating App Maker’s output, the simplest app is:
That’s the basics. So if you’ve a working jar, all you’re lacking it the directory structure, and:
- Info.plist: An Apple plist file, you can use a simple one unaltered.
- launcher: A shell script that launches the jar. This can be 98% templated, with only things like the app name, jar name, and java version needing to be set.
- application.icns: An icon formatted to Apple’s approval.
The Gradle Solution
To generate the app bundle from gradle, I did two things:
- Put the three needed files into src/main/app. The Info.plist and the application.icns are the actual final files. The launcher I modified into a template, using Ant’s templating notation “@VARIABLE_NAME@”.
- Then I added one gradle task to build out the directory structure, and copy the files into place, applying the templating.
Here is the gradle task. I employed some of gradle’s ant support to perform copies and templating.
With the files and task in place all you need to do is run gradle osxApp and you’ll hopefully find build/app/ProjectName.app – a working OS X app.
I could roll this into a Gradle PlugIn but that’s more work then I want to do for this. As it stands, if you want to use this approach, just grab my project that uses it, copy the files in src/main/app and add the task to your build.gradle.
In one of my many “lets try something new” moments I decided to give Kotlin a more serious look. I’d previously run through some of the tutorials but hadn’t gone very deep. This time I decided to set a useful target, and achieve it with Kotlin. I’ve a snippets kata project that I often use, and so decided to port that. At first my intention was to just replace the outside layers with Kotlin, but as I worked more with the language I really got into it, and before I knew it I’d rewritten pretty much everything, keeping only the export/import file format so I wouldn’t loose my data.
- I’m devoted to Gradle so I wanted to use that. Turned out to be a good choice. The Kotlin plugin is clean, simple and functional.
- The code I wrote would be all Kotlin 1.2 targeting Java JVM
- Not really a choice, but figures in, I use IntelliJ as my IDE and it’s very Kotlin aware
- The UI, well I’d used JavaFX previously, and I found TornadoFX, a Kotlin framework for using JavaFX, so went with that.
- I like a visual tool for creating UIs, so used Scene Builder to create FXML files describing the UI
Pretty much, across the board I was happy with my choices and the development was straight forward.
- Kotlin is a pleasure. The language is clean and intuitive. It may be able to run in the JVM, and use existing Java, but the language isn’t another Java DSL. It’s more thorough on topics like, null, immutability, closures, and functional programming.
- TornadoFX alleviated my main JavaFX gripe. I liked JavaFX, but it had a painful style impedance with Java. TornadoFX, on the other hand, fit right into the Kotlin world.
- Scene Builder. It’s stable and workable, better now it’s not Oracle’s product, and Kotlin drinks FXML files flawlessly.
Really didn’t have any complaints, but…
I’m comfortable in the Java ecosystem, and while Kotlin is in that sphere, some Java ecosystem tools won’t play. Some unit testing tools, and annotation based frameworks seemed confused about Kotlin methods.