Focus-android: Enable Kotlin support

[pocmo]

I would like to enable Kotlin support for Focus. My intention is to use it to (and encourage everyone else to) write new code with Kotlin. I have no plans "wasting time" to randomly refactor existing Java code (except when the code needs to be changed anyways).

Some roadblocks:

• How does adding the Kotlin standard library affect our APK size?
• How can we keep code quality tools like findbugs, checkstyle and PMD?

---

mcomella edit: let's track what we need to look into!

• [x] APK size
• [x] Method counts (16838 vs. 16924 - For build with Kotlin support enabled and one class refactored)
• [ ] Code quality tools: findbugs, checkstyle, pmd -> #1308
• [ ] License -> https://bugzilla.mozilla.org/show_bug.cgi?id=1398342
• [ ] "Are we confident that Kotlin will be maintained on Mozilla's timeframe (geologic by internet terms)?"
• [ ] Hurdle of new contributions vs. developer productivity
• [ ] Implicit this references?

[pocmo]

How does adding the Kotlin standard library affect our APK size?

I added the library, automatically converted some random classes and compared the final APK size. For our release builds that are optimized with Proguard I only see an increase of about 15 KB. Our untouched debug builds are ~380 KB larger with Kotlin added. According to methodscount.com the Kotlin library including dependencies has a size of 895 KB (JAR) / 1119 KB (DEX) [6317 methods]. According to the Kotlin docs the size increase in a real life app (with proguard) is less than 100 KB.

[pocmo]

How can we keep code quality tools like findbugs, checkstyle and PMD?

Findbugs seems to look at the compiled code only and reports issues in my local Kotlin code just fine. :)

[ncalexan]

A few comments:

• Hurrah for experimentation!
• If we ever want to ship Focus in mozilla-central, every experiment costs a lot.
• Has Mozilla license reviewed Kotlin, any additional runtime components, any patent grants, etc?
• Are we confident that Kotlin will be maintained on Mozilla's timeframe (geologic by internet terms)?

We need to balance the new shiny with the fact that we're going to be shipping Focus for 5+ years. In this case, I think we should get some experience with the new shiny; but these questions still matter...

[mcomella]

Additional concerns:

• How will the hurdle of having to pick up Kotlin affect new contributions? imo, the primary developer productivity beats out ^ but perhaps worth raising
• When does Kotlin keep implicit references to this? We could add some hard-to-find Context memory leaks (and at a brief glance, Kotlin's behavior seems non-trivial - see this SO post).

fwiw, an easy way to get our toes wet is to write tests in Kotlin (which I already did over in FirefoxData).

---

How can we keep code quality tools like findbugs, checkstyle and PMD?

For checkstyle: a quick search found a small linter project (324 starts) that follows the official Kotlin style guide (no configuration): ktlint.

However, I'm less concerned about checkstyle with a small team of core developers and few contributors – I'll be more concerned when we start adding more developers, and less regular developers.

[mcomella]

Has Mozilla license reviewed Kotlin, any additional runtime components, any patent grants, etc?

The majority is under the Apache 2 license but here are some more specifics to look into: https://github.com/JetBrains/kotlin/tree/master/license

Are we confident that Kotlin will be maintained on Mozilla's timeframe (geologic by internet terms)?

As of May, Kotlin is officially supported by Google for use in Android. That being said, Google does have a habit of suddenly dropping projects they seem to invest heavily in (the Jack and Jill compiler, for example).

To do my own speculation, Java is really starting to show its age and imo Kotlin is its strongest successor (and has an unfair advantage of being developed by the developers of one of the top IDEs) - analogously, it's the Swift of the Java world. In particular, on Android, where we're stuck with Java 6, Kotlin is extremely desired.

JetBrains seems to be heavily investing in Kotlin (e.g. the first ever kotlinconf!) and I haven't seen any red flags so I don't see it going anywhere.

In the worst case that Kotlin support is dropped by JetBrains:

• Kotlin compiles to Java bytecode so our code will never stop working
• But given that JetBrains writes the tools (Intellij, AS), they may stop working well

[mTwTm]

FWIW, here's a document Jing-wei shared with me regarding what Square have considered when they are investigating on whether to adopt Kotlin or not.

https://docs.google.com/document/d/1ReS3ep-hjxWA8kZi0YqDbEhCqTt29hG8P44aA9W0DM8/edit

[chetgurevitch]

How will the hurdle of having to pick up Kotlin affect new contributions? imo, the primary developer productivity beats out ^ but perhaps worth raising

Kotlin seems very easy to pick up for anyone familliar with java and eases a lot of development pains. I could honestly see supporting java exclusively become a larger discouragement to new contributors in the near future.

Also worth noting Google are working with Jetbrains to create a non-profit foundation so things really are looking very solid.

[ioana-chiorean]

Is this something we might consider for Firefox for Android too?

[mcomella]

Is this something we might consider for Firefox for Android too?

We should continue this discussion on Firefox for Android channels but I think the situation there is a little harder – we're quite close to the APK method limit, in the past we've strived to keep our download size down, and the split build toolchain will make integration more complicated.

Bug 1322543 was filed for using Kotlin in Firefox unit tests - perhaps that'd be a good place to continue the discussion.

[pocmo]

Is this something we might consider for Firefox for Android too?

Eventually this might happen. For now there are too many other battles to fight. Once we have switched to a modern build system ("full" Gradle) then we can start to think about that. The method limit is a concern. But this is a limit we are going to hit sooner or later regardless of Kotlin. I guess once our builds are nice then switching to Multidex will be less painful too.

[pocmo]

Legal review:
https://bugzilla.mozilla.org/show_bug.cgi?id=1398342