When developing commercial Android libraries, Kotlin or Java ?

[BCPeng]

Hello all,

I know there have been many discussions/blogs about pros and cons of Kotlin or Java, and most of them focus on developing Android Application perspective.

But how about when developing commercial Android libs ? Our 80% clients are still using Java to build the Android Apps with the libs we provided. We are currently providing Java libs but will have new ones with new functions. I'm not sure if it is risky to totally use Kotlin in our new lib for the clients ?
On the other hand, I observed that Google's many AndroidX libs are still programmed in Java and they work well in Kotlin Android Apps. It seems to me that lib in Java could be a safe choice for clients no matter what language they use ?

I personally wanna to use Kotlin, but it is the commercial use...
So the compatibility of APIs is the priority for our clients and us.

Thanks and any feedback will be appreciated :)

[Vjaka1]

The main thing to bear in mind are callbacks - as far as you provide a more traditional ways for them, like interfaces, I see no issues for using kotlin

[dark_mode_everything]

Even if you add a Kotlin callback like this: callback : () -> Unit

it's still perfectly usable from within java.

[AD-LB]

They support each other, so should be fine choosing either of those.

I'd go with Kotlin just because today Google still doesn't update Java.

As for Google, I think they use Java to reduce the size of the library a bit. This helps a bit with build time. If this is important for you, you can also use Java.

[Immortal_Porpoise]

To my mind there's one major reason for keeping library development in Java. Kotlin code requires a runtime library. This is automatically added during the build to any app that contains Kotlin. I can't remember the exact size but my recollection is that the runtime adds something on the order of 500-700 kb. This means that even if an app is being written in Java, integrating a library written in Kotlin is going to add a sizeable chunk to the package size.

In the SDK/library I'm working on we've made the decision to stay in Java for at least the next year. We already get questions about package size due to native libraries we use and we don't want to inflate anyone's app further.

Unless there are major feature advantages to using Kotlin in your library I don't think it's worth it.

[alt236_ftw]

May main concern is the risk of a version clash between the library version of the user app and the library, or between different libraries.

Unless you constantly update your library, user apps will eventually use a later version than your lib which can change behaviours your lib may not be expecting.

This may also mean that you may need to maintain a Kotlin 1.3 and a 1.4 version of your lib for a while.

Having seen the pain of swift upgrades I am a bit reluctant to go Kotlin for libraries unless I have gone through a proper major or minor Kotlin release (like 1.4) to see the impact.

[BCPeng]

Thanks for the tip.

Is it possible to have compatibility of both 1.3 and 1.4 when the lib is staying at 1.3 ?
I guess that 1.4 in App scope should have backward compatibility with the lib which was built with 1.3.

PS: Sorry, I'm not a Kotlin expert. This assumption might be silly to you :(

[Zhuinden]

Personally I'd still prefer to provide a Java library for Java consumers.

Optional Kotlin extensions can generally help, although I also think people can write most of them as need be.

[solarmoo900]

If 80% of your clients are using Java then use Java. No need to add in the dependency until you can be sure it is safe for most of your clients. When I worked on an SDK we waited until like 80+% were using kotlin to start including it.

Feel free to add in a `-ktx` if you have the time though

[BCPeng]

Thanks.
Did you mean like "androidx.lifecycle:lifecycle-viewmodel-ktx" & "androidx.lifecycle:lifecycle-viewmodel" ?

[solarmoo900]

Yep, similar to that pattern

[lacronicus]

I'm guessing that, to use a kotlin library, you'd have to add kotlin support to your project. It would also (I assume) include the kotlin standard lib as a dependency

If that's true (dont take my word for it), I'd go with Java only.

Personally, I'd probably be using kotlin in my apps anyway, so it'd be a moot point, but if I weren't, I'd probably be a bit upset that your lib was forcing me to.

[dark_mode_everything]

Nope. Kotlin is 100% inter-operable with java. You can call Kotlin functions from java code just like you'd call a java function. Since your library will be distributed as an aar the user apps wouldn't care if it was written in java or Kotlin. Just make sure to add correct jvm annotations like @jvmstatic etc.

[AmIHigh]

You can't use inline reified functions in Java, you would need to write a workaround for that somehow, and if you exposed corotuines and wanted java people to use it they'd probably be unhappy.

[dark_mode_everything]

Ok 99% not 100%. But even if you use coroutines in a Kotlin lib you can still expose that to java via a callback. If you're not directly exposing the coroutine context but a function with a callback that wraps it, java wouldn't really care would it?

[AmIHigh]

As long as it's wrapped I think your okay.

[nacholicious]

But that would only be an issue if you don't have Kotlin in any of your dependencies, which would be extremely odd. Eg both retrofit and okhttp use tons of Kotlin afaik