Convert to Kotlin? Feedback from Android and Kotlin devs appreciated...

[GlenKPeterson]

Instead of converting UncleJim to Java 7 or Java 6, we could convert the whole thing to Kotlin and compile it to Java 6 from there.

"Kotlin generates bytecode which is compatible with Java 6 or newer. This ensures that Kotlin can be used in environments such as Android, where Java 6 is the latest supported version."

I started my new project at work this week using Kotlin. I've only used it for 2 days, but so far it looks amazing! They have shaved off all the backwards-compatibility warts of Java (like primitives and arrays) and added a few of the safer parts of Scala. About the only syntax I really even had to look up was the lambda syntax which is different from either Java or Scala, but certainly no worse.

One alternative for Android developers is a back-port to Java 6 or 7, but that's going to be pretty difficult due to the default methods in interfaces. What if we convert the whole thing to Kotlin and compile it to Java 6 from there? Or maybe Android developers would rather use Kotlin?

Does Kotlin require a runtime library on Android? If so, how big is it? Other considerations? If you work in Android and/or Kotlin or have any relevant experience, your feedback would be appreciated.

[pniederw]

Kotlin is great for apps. However, using it to implement a foundational and language-agnostic library such as UncleJim is problematic:

1. Imposes additional runtime dependencies (kotlin-runtime and kotlin-stdlib) on all library users, increasing total code size (by ~400% in UncleJim's case) and chance for version conflicts.
2. Effectively imposes Kotlin on library users, e.g. when they browse or debug code. Not only will users need to understand the language, but they will also need to have a working Kotlin debugger/IDE setup, even if their project has nothing to do with Kotlin.
3. Library users of the library will impose 1. and 2. on all their users.

Due to 3., I wouldn't be able to use UncleJim if it was written in Kotlin. I hope the Java 8 version is here to stay.

PS: Dexx is a persistent collections library that offers a Kotlin add-on to improve Kotlin interoperability. Nevertheless, the core module is written in pure Java, likely for reasons similar to those I outlined above.

[GlenKPeterson]

Thanks for this. You make good points.

You touched on the question of where UncleJim is headed. "Writing Java the way I'd write Clojure, but with types" has been a primary motivation. The next logical step is to make a language that uses these collections as the built-in data-types (like JSON in JavaScript or the built-in data types in Clojure). UncleJim would stay in Java for maximum interop between Java and the new language.

I think Java 8, with lambdas and default methods on interfaces is the biggest step forward since Java 5 with generics. I needed Java 8's improvements to get this put together in a reasonable amount of time. I don't know what the future holds, and I may make a branch for Java 9, or maybe some day for Kotlin. Either way, I'm not planning to do away with the Java 8 version so long as it's still supported by Oracle. I figure for the Android developers, they'll have Java 8 at some point too, so there's just this short-term gap to cross.

[cbruegg]

they'll have Java 8 at some point too, so there's just this short-term gap

Perhaps in a few years when Android Nougat has a market share of 75 % or more. Before Android Nougat, only lambdas are supported, but not default methods.

Porting to Kotlin would be very appreciated. I don't think users would need to have a Kotlin compiler installed, the IDE plugin would only be needed to view library sources properly. Otherwise, UncleJim would be seen as a regular JAR without sources.
Version conflicts shouldn't be happening since the Kotlin team has promised binary compatibility for future releases of Kotlin with older ones, meaning that when Maven compiles an application using the latest requested version of the runtime/stdlib, it should work fine.

Still, a solution using Java 6 at its core + a Java 8 and Kotlin frontend would work as well. If you need any help with Kotlin, maybe I can lend a hand.

[Takhion]

One extra point in favour of Kotlin is that they are going to provide soon a way to compile the same code to different targets, like Java 6 (default) or Java 8 (with native lambdas & default methods in interfaces). Plus with Kotlin it's possible to explicitly inline functions, which would probably make for some performance improvements and even more code re-use.

[GlenKPeterson]

Thanks everyone who added their input. Version 4.0 looks like a rewrite in Kotlin. Not sure yet if this project will eventually merge with https://github.com/kategory/kategory but that's a possibility. If you're using Kotlin and Java now, you may want to try version 3.1 in the KotlinFootWetting branch to avoid namespace collision with the Mutable collections. In the 4.0 branch, we're implementing the Kotlin interfaces, so it won't be an issue. If you're all Java, stick with 3.0 as the name changes in 3.1 will probably be reverted in 4.0.