Proposal: Kotlin rewrite

[ZacSweers]

Kotlin rewrite

Currently, we have main AutoDispose java artifacts in Java and corresponding -kotlin artifacts for each of them. This works, but we would like to leverage more modern language features (#10, #197), better nullability handling (we currently use NullAway and javaxextras), simplifying the codebase with kotlin's expressiveness (particularly around exception handling).

Goals

(inspired by Okio 2's design doc)

It should be 100% API-compatible with the current Java API for Java and Kotlin uses of our library. This includes using the same Maven coordinates, the same package name, and an upwards-compatible API. We should use build tools to confirm this compatibility.

It will be implemented in Kotlin! And it will depend on the Kotlin standard library. By implementing it in Kotlin we give ourselves the option to later support Kotlin/Native and Kotlin for JavaScript. We also give ourselves the option to later support coroutines.

It should have equivalent performance to the current java implementation. We may need to write careful Kotlin, paying attention to abstractions that have a runtime cost.

Existing -kotlin artifacts and their APIs will be merged into the main artifacts.

FAQ

Why Kotlin? Because it’s really good. It’s a wonderful language to build Java libraries and applications with. It has abstractions that make it possible to write code that is both compact and efficient.

But isn’t Kotlin just a trend? Not if we have anything to do with it. By doing AutoDispose in Kotlin we’re making a big commitment to the language, and we hope others will follow us here.

What would the cost imposed on Java users be? Nothing if we can help it. The standard library would be a transitive dependency, but it is extremely small (~500kB) and proguards well.

Extra reading: Okio 2.0 design document

Discussion

This is a discussion proposal and not a formal plan yet. Please do comment if you have thoughts/concerns/proposals/etc.

[ZacSweers]

After some healthy offline discussion, we are not going to move forward with this right now. We love Kotlin, but for AutoDispose we believe it doesn't make sense.

Some of the gains would be small wins at best

Unify core and kotlin artifacts

We're hoping that Kotlin/KEEP#111 facilitates making this easier in a pure Java library in the future, and plan to keep an eye on that long-term.

Modern language features

Only useful for us, not consumers

Free/automatic nullability annotations

This is not really a problem today though. Plus, we build with NullAway to catch any issues in this regard.

Some of the other theoretical gains, after further discussion, are not realistic/clear right now

Kotlin native support

Not really a feasible because at the end of the day, AutoDispose is an extension on top of RxJava and RxJava is not written in kotlin/available for multiplatform. We would have to talk to custom interfaces for interop/bridging with Rx. While this might be useful to maybe make AutoDispose able to work with something like RxSwift or RxJS, we lean heavily on RxJava's APIs as well. These APIs might not even exist or carry the same behaviors in other constructs. We don't know enough to make an informed decision right now unfortunately.

Kotlin coroutines support

Similar to the above - AutoDispose is at its core an RxJava extension library. Coroutines have different semantics, and it's unclear how much of the semantics here are transferrable.

Which leaves us with...

But kotlin is cool!

It is :). But as library maintainers, we're optimizing for the developers consuming it. With the current considerations, this would be of neutral benefit to kotlin users and potentially negative benefit to Java users (debugging, standard library dependency). That is not enough of a case for us to pursue this, so we're not going to. We do plan to continue using Kotlin freely in places without downstream side effects, such as in static analysis tooling we ship and obviously our kotlin extension artifacts.

What we might explore in the future is extracting AutoDispose's core to an RxJava-agnostic implementation. It's unclear how useful this would be though, as AutoDispose' internals lean heavily on RxJava functionality as well. Maybe it'll be the whole disposal/concurrency system, maybe it'll just be the high level ScopeProvider interface. Maybe we can just support coroutines and let coroutines bridge to RxJava/RxSwift/Rxwhatever! Suggestions are always welcome.