Migrating this repo codebase to Kotlin

[surbhiia]

As Kotlin is being increasingly used for development of android applications and is now the preferred language by Google, it might be worth migrating this repo codebase to Kotlin. This 2019 stack overflow survey shows kotlin is in the top 5 most loved languages.

[LikeTheSalad]

This is a topic where I believe it'd be ideal to get as much input as possible from different people. I personally prefer using Kotlin, and to be honest, we'll most likely end up doing the migration, however, I wanted to mention a couple of reasons why (at least in Elastic) we also decided to use Java in our agent to see if those make sense from a broader community's perspective.

• Android devs might not be the only ones interested in reading and modifying code related to observability, maybe people from DevOps teams for example might want to have a look and create a PR, and in those cases, since Java has been around longer than Kotlin, it might be easier for someone without an Android background to understand it rather than Kotlin, making a wider range of people able to quickly contribute some changes.
• Even though Kotlin is the indisputable winner when choosing a language for Android projects, it is technically possible to create an Android project using Java only, in those cases, if we decide to use Kotlin as part of the core of this library, we'd be enforcing Kotlin's transitive dependencies on the host project, such as Kotlin's standard lib, which is not particularly lightweight, and usually app size is an important topic in Android.

I believe that if the above reasons are not a problem for anybody, then we should definitely make the migration.

[marandaneto]

My 2 cents.

• Most if not all androidx libs are Kotlin first, including the dev tooling, eg AGP, etc.
• Kotlin is considered the first option for Android development.
• App size is indeed a concern, although ProGuard or R8 do Tree Shaking quite well, not sure if it works for the stdlib though, most likely yes since it's a dependency as any other, and the other reason is that apps most likely already have the Kotlin stdlib as a transitive dependency anyway.
• Java and Kotlin are very similar, even if you copy-paste Java code into AndroidStudio, AS auto converts to Kotlin, so I don't think it's gonna be a problem for people that never used Kotlin but are good at Java.
• Instead of a full migration, it'd be fine to also start with Kotlin for the new stuff.
• Usually the Kotlin compiler is slower than Java, but as an SDK and very niche (small code base as well), I don't think this is a problem, or it'll be.
• Using Kotlin is one step closer to offering an OTel SDK for Kotlin Multiplatform.
• Kotlin has a nicer UX in my opinion.

Overall, I'm all in for Kotlin first, but no strong opinions since there's interpretability.

One important aspect is that we pay attention to the Public APIs. If it's written in Java, the APIs should be friendly to Kotlin as well and vice versa, for example, Kotlin should have method/ctor overloads and not force Java caller to pass all the optional parameters, etc.

[yogurtearl]

Writing your Android SDK in Java and not Kotlin is akin to writing your iOS SDK in objective-C and not Swift.

Even though Kotlin is the indisputable winner when choosing a language for Android projects, it is technically possible to create an Android project using Java only, in those cases, if we decide to use Kotlin as part of the core of this library, we'd be enforcing Kotlin's transitive dependencies on the host project, such as Kotlin's standard lib

As noted above, this is a non-issue and Google imposes this dependency for apps using androidx, which is all but required for a modern app.

I can't imagine an app being modern enough to use otel-android while not using androidx

From https://developer.android.com/kotlin/stories

Read more to see why over 95% of the top 1000 Android apps use Kotlin.

Android devs might not be the only ones interested in reading and modifying code related to observability, maybe people from DevOps teams for example might want to have a look and create a PR, and in those cases, since Java has been around longer than Kotlin, it might be easier for someone without an Android background to understand it rather than Kotlin, making a wider range of people able to quickly contribute some changes.

Alot of DevOps teams have golang experience, and I would imagine Kotlin is easier to digest for a golang developer than Java.

[yogurtearl]

Also, this repo is already using kotlin for the build scripts (*.build.kts), so it has a nice synergy there.

[bherbst]

In addition to the direct benefits to the opentelemetry-android codebase and the benefits to consumers in using the APIs, I suspect that opentelemetry-android will soon reach a point where shipping the Kotlin stdlib is inevitable and trying to avoid doing so would limit the utility the library can provide.

In particular, many AndroidX libraries such as androidx-lifecycle are already written in Kotlin, and we could benefit from leveraging those APIs.

Similarly, OkHttp 4.0 went 100% Kotlin all the way back in 2019 with relatively little fanfare or pushback - I'd expect even less for an Android-specific library. They also noted that when they did the same with Okio, the final cost of the stdlib was just 7kb.

[bidetofevil]

I think a good start is having new code written in Kotlin and then porting bits piecemeal as appropriate. I know the focus right now is the build out functionality rather than refactor, but that's a good way of getting a foot in the door.

[LikeTheSalad]

Thank you all for your feedback! Based on the comments, I think it's clear that there shouldn't be any issues with migrating this lib to Kotlin and I think there are great points that dismiss the concerns mentioned in my previous comment, for the Kotlin lang knowledge, it seems like the people who wants to be involved here don't have issues with using it, and also, regarding the app size issue, it's certainly the case that at one point or another, we'll include some dependency that already contains the Kotlin stdlib, I actually know of one that will do so already which is the OTLP exporters one, it uses OkHttp 4 which was written in Kotlin as mentioned by @bherbst so it should be fine.

I agree with @bidetofevil, we should start by having new code written in Kotlin, and luckily I think the whole project isn't that large atm so whenever we're ready to do a refactor it probably shouldn't be too painful to do so.

[steve-the-edwards]

Would be very happy to see this library move to Kotlin! This is exciting!

[marandaneto]

I think the only real problem we might face is version compatibility, people using an older version of Kotlin, so it is always good to set jvmTarget, languageVersion, and apiVersion as low as possible, probably to the last non-deprecated version. As long as we communicate well the Kotlin min. version, it's fine, people can always use an older version of the OTel SDK for a while.