[RFC] Refactor Android java API to kotlin

[kirklandsign]

Motivation

• Kotlin is a modern language.
• It has become the preferred language for Android development.
• It has better syntax and readability.
• It has null-safety features and smart casts reduce the likelihood of NullPointerExceptions, making our API more robust and reliable.
• It can automatically deduce the type of variable.

Expected results

• java files under extension/android/executorch_android will be refactored into kotlin.
• We utilize conversion tool to do this, then fix error and test.
• For ExecuTorch Android java API, the class and method signature will not change. Existing users using executorch-android package, regardless of using java or kotlin in their code, do not need to update their call site. Therefore, minimal impact on existing users.
• javadoc should not change (or minimal) in the refactor.
• bytecode of executorch-android .class files should not change (or minimal) in the refactor.
• [Potential developer impact] Current ExecuTorch Android contributors may need to rebase and refactor their work (for example this issue) if they are already working with java. For developers who read the java source code, they need to read the new kt code.

Testing

• We will use our existing unit test and instrumentation test to validate everything works.
• Compile and use llama demo app, and executorch demo app as before.
• We compare the .class files during refactor. Likely they won't change.

[mergennachin]

What are possible cons of doing this?

[kirklandsign]

Not that I can think of. Java and kotlin are fully interoperable. It's more like two compiler front ends, and the backend is the same.
Java: .java -> javac -> .class -> d8 -> .dex -> Android runtime (ART)
Kotlin: .kt -> kotlinc -> .class -> d8 -> .dex -> Android runtime (ART)

[kirklandsign]

We expect the .class be almost the same

[byjlw]

More clarity on the outcome would be nice. Ideally a kotin developer with no prior ET knowledge should be able to read the RFC and answer the question, "does this solve my use case" Some linking is ok to reduce the amount of copy paste but users shouldn't have to search around or think too much.

Also include the testing / validation process to ensure that things work for kotin engineers, existing java folks aren't broken, and nothing else was broken in the process.

[kirklandsign]

A kotlin developer can develop their app on ET the same way as before (when we implement the API in Java)

[kirklandsign]

Added the test description

[mergennachin]

What about existing JNI layer implementation? Will it change?

[kirklandsign]

No.

[phaiting]

I want to share some perspective for adopting kotlin:

• Kotlin has become the standard for Android development: Google announced Kotlin as the preferred language for Android and new libraries are developed Kotlin-first. We will see more and more libraries entirely built for Kotlin (e.g. Jetpack Compose by Google).

• Kotlin is a better language: Kotlin was developed to address many of the shortcomings of Java:

  • Kotlin is a safer language due to built-in null safety.
  • Kotlin is more expressive, and reduce the total lines of code. Less code means less reading, less writing, and less bugs.
  • Kotlin is fully interoperable with Java.

While the executorch android API is continuing to grow, adopting kotlin early would give us all the benefits and also reducing the cost of convention if we do it later.