IMPORTANT NOTE: This is currently just a proposal capturing my arguments for eventually doing this and suggestions for possible approaches, not an accepted policy. Do not send PRs that migrate plugins. The documented policy is still to use Java for almost all plugins.

I think there a number of compelling reasons that we should use Kotlin for all of our 1P plugins:

• Maintenance benefits:
  • Kotlin is a safer language. Notably, it has strong type safety and null handling, like modern Dart, which eliminates whole categories of errors (errors which have caused bugs in our plugin for the entire time I have been on the ecosystem team). It also has a modern concurrency system that has safety benefits over callbacks, guaranteeing that an async operation doesn't have codepaths that complete anything other than exactly once (particularly important for method channels).
  • Kotlin is, IMO, more like Dart. The type system, concurrency system, collection operations, etc. are much more similar to Dart than Java's, which I find makes moving between them easier. For the ecosystem team, this is particularly valuable, as we deal with more languages, so the more similar they are the better (and Swift, which we are actively moving to is also more like Dart and Kotlin).
  • We plan to remove the Java Pigeon generator, and have therefore switched essentially all of our plugins to the Kotlin generator, so currently most plugins are hybrid. While the Kotlin code is generated rather than human-maintained, there are some mismatches that make the Java code slightly awkward, especially around Pigeon's use of the Result Kotlin type, leading to shims like this.
  • The build files for our plugins are all Kotlin now, so replacing Java with Kotlin would reduce the overall number of languages in the repo by one.
• Community benefits:
  • The community often looks to our plugins as examples. The flutter create default for a new plugin has been Kotlin for many years now, so our Java code is not as useful an example for other developers.
  • Relatedly, if we want our plugins to serve as examples of good practices that LLMs will draw from, having them be in the language developers are likely to be using will make them more likely to positively influence generated code.
  • Our experience will better match the community's, shaping our development priorities in ways that better align with the community. For instance, I think it's very likely that we would have prioritized adopting modern concurrency in Pigeon's Swift and Kotlin generators if we had been using those languages, since historically Pigeon development has been driven mostly by our own actual usage.
  • To the extent that both our create defaults and Android's Kotlin-first model encourage Android plugin developers to learn Kotlin, not Java, having our plugin be Kotlin would make community contributions to our plugins (PRs, reviews, etc.) easier. (I would also expect that the increased safety would make reviewing easier in the long term.)

Potentially useful references:

• The corresponding Swift umbrella issue.
• The Swift migration design doc, which has some discussion about migration strategies that can be useful. In particular, migrating unit tests and implementations as separate PRs is something I would strongly recommend here, to minimize the potential for regressions.
• My original (now 5 year old!) design doc proposing Kotlin usage, although it's definitely outdated in many respects.