| Australia | 30% |
| Canada | 25% |
| China (Mainland Incorporated) | 10% |
| China (Offsohore Incorporated) | 0% |
| Hong Kong | 0% |
| Japan | 20.42% |
| Singpaore | 0% |
| Singapore REITs | 10% |
| U.K. | 0% |
| U.K. REITs | 20% |
| U.S. | 30% |
Source: https://www.spglobal.com/spdji/en/documents/additional-material/withholding-tax-index-values.pdf
It has been while since I start a
new JVM project. I needed to build something quick and dirty, e.g., within a
day or two, so I went with something I was most familiar with, Spring Boot, to
get the project up and running.
It has been a while, but Kotlin
has been the crazy a few years back and I had used it a few times with my
previous employer. It is now a choice among the JVM languages. I have been away
from the JVM space for more than a year (and boy, do I miss it), so it was
either Java or Kotlin for me. I went with Kotlin just to keep it interesting.
I went with the Spring Initializr, picked my poison and got my project up in no time. It is a
simple Web-MVC application, with one simple page with a form, some REST API
call out to other services, and read only to database. Picking Gradle for build
and Kotlin for language, the project generated a Kotlin base build file build.gradle.kts. This is new to me, but the script is
still very readable, so no extra learning curve here.
Last time I used Spring Boot
with Kotlin, I recalled there are little things here and there that we need to
"tweak" to get Spring Boot feature to work properly with Kotlin.
These "tweaks" feel like some inherent mismatch between Spring
Boot and Kotlin. For my new recent project, it appears all these “mismatch”
still exist.
For example, to use Kotlin data
class as @ConfigurationProperties object, we need to add this @ConstructorBinding
annotation to the class and add “kapt” plugin to the project. This feels like
some sort of workaround for some incompatibility between Kotlin data class and
how Spring Boot @ConfigurationProperties works.
Next adding spring-data-jpa
support with Kotlin, we need to add another slew of plugins “plugin.allopen”,
“plugin.noarg”, “plugin.jpa”, and some custom extra gradle configuration:
allOpen
{
annotation("javax.persistence.Entity")
annotation("javax.persistence.Embeddable")
annotation("javax.persistence.MappedSuperclass")
}
These little problems are often the reason why many “experienced” developers still refuse to adopt higher order frameworks such as Spring Boot and Ruby and Rails, and prefer to keep rolling their own, copy-and-pasting from past projects, because when the magic works, it is awesome, but if it doesn’t, trying to find the problem on your own is like trying to find a needle in a haystack. This is the size of the ecosystem matters, and the good old Spring Boot and its "Google-able-bility" is still top notch.
The target deployment environment
is Kubernetes and I had experience using Docker and Dockerfile to build image,
but Spring Boot simplified this for me and all I need is run gradlew bootBuildImage. With a little bit more work to setup the
Gitlab pipeline to use kustomize and kubectl to push to EKS, the application
was up in a day.
This got me thinking: Is Kotlin still a good choice for JVM based backend today?
With Java 17 LTS fast approaching, and many awesome language features added since the last LTS, such as java records in Java 16, it appears the language level gap between Kotlin and Java has shrunk. So, does it still justify using Kotlin, knowing that all these little incompatibility between the language and other frameworks? I think I found my answer in a comment by rzwitserloot in r/java.
