Adopt Kotlin

[ezaquarii]

Is your feature request related to a problem? Please describe.

Project is Java-only.

Describe the solution you'd like

Enable Kotlin support.

Additional context

Kotlin is now considered 1st class citizen in the Android universe.
Examples in the internet are in Kotlin.
New developers start in Kotlin.
Contributors look for first Kotlin experiences to increase employability.
It gains traction.

Key battle-proven facts about Kotlin:

1. Java interop is spectacularly good - there is almost no friction
2. data classes make Lombok obsolete
3. tooling has matured enormously in recent months (checkstyle, ktlint, spotbugs)
4. null-safety provides tangible quality benefits
5. migration from Java code is semi-automated and - while not perfect - works above expectations

[tobiasKaminsky]

I am not strictly against using Kotlin, but how would it end like? New stuff in Kotlin maybe, if the contributor writes code in it, older things still in Java.
Also me and also Andy, as far as I know, do not have knowledge in Kotlin, which is of course no big deal, but will slow down development speed at beginning.

Do you have suggestion, how both languages can co-exist well together?

[ezaquarii]

Yes, I have positive experience in that area. Also, you can find Objective-C/Swift migration in Apple ecosystem very informative - I'd strongly encourage you to reach iOS developers for advice, as Apple community is resolving very similar issue and their experience is - in my opinion - comparable.

It's good to start small first. I'd propose to encourage Kotlin usage in unit tests first. This code is non-critical, not client facing, relatively simple (short functions without interdependencies), giving a production-grade playground to familiarize developers with the language, integrate new tools (lint, static checkers, etc) and getting familiar with gotchas (final classes by default, mocking is done differently). Because Kotlin is testing Java, this is also excellent training ground to gain Java interop experience - the key issue is null-safety of Kotlin and nullability of Java types.

Once the core developers become comfortable, you can try different approaches:

1. introduce new functionality in Kotlin
2. use Kotlin in selected packages / components only
3. rewrite some simple Java component into Kotlin

Rinse-repeat the process as necessary.

My observation is that any Java developer starts writing Kotlin code after a 1-day of tutorial or just learn on the go, using syntax cheat sheet and it worked pretty well - they call it "a better Java" after all and I think it's a good summary. Idiomatic Kotlin comes with time, refactoring is as easy as in Java.

Maybe my experience is a feature of my particular work environment, so I will accept a different testimony, although judging from the level of complexity you guys deal with on daily basis, I'd assume my faith is well placed.

I do not have any experience with external contributors, but judging from the top active contributors list, this should not be a massive setback - majority of new code comes from 3 developers only.

[AndyScherzinger]

Like Tobias guessed correctly I don't have any experience with kotlin but would be eager to learn kotlin and also think that starting with the test part would be a nice thing. Other than that since I usually have my personal focus on the UI part it is also less of an impact to me since layouts are XML based :)

Other than that like you mentioned, doing this on a per component basis makes sense while we then should check how to balance this with moving forward work items regarding certain frameworks like room, work manager, jetpack in general, glide etc. 👍

[tobiasKaminsky]

On my previous job I used scala, which was also very easy to start with, if one knows Java.
The idea to start with testing is a good idea.
I also started to migrate UserInfo to room/jetpack/android components. So there it might also make sense to directly switch to Kotlin. However I'll need to find some time to finish it…