Add Java, Lombok and Kotlin post.
authorOlof-Joachim Frahm <olof@macrolet.net>
Thu, 18 Aug 2016 19:39:56 +0000 (21:39 +0200)
committerOlof-Joachim Frahm <olof@macrolet.net>
Thu, 18 Aug 2016 19:58:24 +0000 (21:58 +0200)
lombok-kotlin.post [new file with mode: 0644]

diff --git a/lombok-kotlin.post b/lombok-kotlin.post
new file mode 100644 (file)
index 0000000..bde9557
--- /dev/null
@@ -0,0 +1,33 @@
+;;;;;
+title: Java integration woes
+tags: java,kotlin
+date: 2016-08-18 21:26:13
+format: md
+;;;;;
+
+Just a quick note on the JVM ecosystem since I've been wrestling with getting
+several different technologies to work together:  It's a mess really.
+
+The specific setup in this case is a mostly Java based project, sprinkled with
+some Kotlin code (which I only expect to grow in the future), using Maven as
+the build system.  Added to that some Kotlin annotations (in lieu of using
+Kotlin in the first place).
+
+Todays (and yesterdays) adventure was trying to get the Error Prone checker
+integrated with the existing system, which proved quite impossible, due to the
+fact that it's using a modified compiler(!) which conflicts with the use of
+Lombok annotation processing.
+
+There are workarounds in the sense that Lombok can also be used to produce
+processed Java files (instead of byte code generation), however it seems like
+that process is less capable than the IDEA / internal processing and would have
+me remove a lot of `val` instances that didn't get their type inferred
+properly, making it an arduous process.
+
+Summing this up, the fact that these tools integrate on different levels of the
+"stack", while also making tinkering with it relatively hard due to byte code
+generation, complicates this endeavour greatly.  In the end I resolved to drop
+the Error Prone integration in favour of the much easier to setup SonarQube
+platform.  I also hope that annotation processing for Lombok will improve such
+that we don't need workarounds in case of "invisible" getters anymore, for
+example.