Kotlin in First-Party Android Plugins

[stuartmorgan-g]

Proposes changing the guidance for flutter/packages development to recommend Kotlin, rather than Java.

[stuartmorgan-g]

Per recent discussion. Please let me know if there is other reasoning you'd like me to capture here, or if you'd like to adjust the recommended policy text at all.

[jtmcdole]

This looks fairly straight forward. Would there be any reason to suggest migrating Java plugins to Kotlin with AI tooling?

@mboetger - assuming you lgtm, also add the assign-rfc-number label.

[github-actions]

Failed to automatically assign RFC number. Check workflow logs for details.

[jtmcdole]

RFC Number Assigner / assign-number (pull_request_target)Failing after 18s

OK, that's what I was afraid of.

[jtmcdole]

I tried to be smart and have a dual-checkout, but github / actions/checkout caught this:

Error: Refusing to check out fork pull request code from a 'pull_request_target' workflow. This workflow runs with the base repository's GITHUB_TOKEN, secrets, default-branch cache scope, and runner access. Fetching and executing a fork's code in that trusted context commonly leads to "pwn request" vulnerabilities. To opt in, review the risks at https://gh.io/securely-using-pull_request_target and set 'allow-unsafe-pr-checkout: true' on the actions/checkout step.

I'll research it more.. but let me see if I can unblock.

[jtmcdole]

While I have a solution, it will still require users to allow maintainers to push to their repository (needs instructions). To get past this, simply run:

dart run bin/assign_rfc_number.dart

And it will assign and update your files.

[stuartmorgan-g]

Would there be any reason to suggest migrating Java plugins to Kotlin with AI tooling?

Personally, I think the deterministic Android Studio conversion is a much better starting point than AI. On the iOS side, where there is no such migrator, I've used Gemini to do first-pass conversions and it has an unfortunate tendency—even when specifically prompted to keep the exact same structure for easy side-by-side reviewing—to do a pretty good job on 95% of it and then randomly drop or change 5% of the logic. That makes reviewing for correctness very tedious because you have to check every single line. The AS conversion, because it's just deterministically applying rules, never does that. Then the review can focus on the follow up diffs to that mechanically converted base, which are much smaller.

[stuartmorgan-g]

@jtmcdole I'm not entirely sure what the process is here at this point; do I just land this now that it's approved?

[jtmcdole]

@jtmcdole I'm not entirely sure what the process is here at this point; do I just land this now that it's approved?

As the primary owner of 720 (package ecosystem) and having gotten the approval of the Android TL, you could:

1. Consider presenting at a dash forum if you're seeking more input (this doesn't seem likely)
2. Land the RFC (status: stable in the yaml frontmatter and merge)

[stuartmorgan-g]

1. Consider presenting at a dash forum if you're seeking more input (this doesn't seem likely)

Nope, this has already been pre-socialized among the stakeholders.

2. Land the RFC (status: stable in the yaml frontmatter and merge)

I would have forgotten to change that, thanks!

[stuartmorgan-g]

It would be nice if that linter were a presubmit :)

[jtmcdole]

Oh shoot - that should be!

[jtmcdole]

... it skipped it for some reason. will take a look tomorrow

[jtmcdole]

lints should now run in PR as expected.