Repository navigation
Update Android plugin language guidance - #192906
Conversation
Change the policy for flutter/packages to prefer Kotlin rather than Java for new code, per [RFC 720.0001](https://github.com/flutter/rfc/blob/main/rfc/720.0001-kotlin-in-1p-plugins.md) Part of flutter#188630
There was a problem hiding this comment.
Code Review
This pull request updates the Android plugin development policy in the documentation to clarify language usage guidelines. The reviewer suggests restructuring the list to better distinguish between non-migration and migration PR requirements for improved logical clarity.
| - Android: Depends on the plugin. For non-migration PRs use: | ||
| - Kotlin if the plugin is already in Kotlin, or for new plugins. | ||
| - Kotlin when adding a new file to a Java or mixed-language plugin, unless there | ||
| are interop issues with existing Java code that make doing so difficult. | ||
| - Kotlin when adding new tests (when feasible). | ||
| - Java when modifying existing Java code. | ||
| - **Note**: Only Flutter team members may migrate an existing plugin's Java code | ||
| to Kotlin, due to the potential difficulty of reviewing such PRs; migration | ||
| PRs from non-team members will be rejected. |
There was a problem hiding this comment.
The current structure lists the migration policy note under the bullet point introduced by 'For non-migration PRs use:'. This is logically contradictory. Consider restructuring the list to separate the guidelines for non-migration PRs and migration PRs clearly.
| - Android: Depends on the plugin. For non-migration PRs use: | |
| - Kotlin if the plugin is already in Kotlin, or for new plugins. | |
| - Kotlin when adding a new file to a Java or mixed-language plugin, unless there | |
| are interop issues with existing Java code that make doing so difficult. | |
| - Kotlin when adding new tests (when feasible). | |
| - Java when modifying existing Java code. | |
| - **Note**: Only Flutter team members may migrate an existing plugin's Java code | |
| to Kotlin, due to the potential difficulty of reviewing such PRs; migration | |
| PRs from non-team members will be rejected. | |
| - Android: Depends on the plugin.\n - For non-migration PRs, use:\n - Kotlin if the plugin is already in Kotlin, or for new plugins.\n - Kotlin when adding a new file to a Java or mixed-language plugin, unless there\n are interop issues with existing Java code that make doing so difficult.\n - Kotlin when adding new tests (when feasible).\n - Java when modifying existing Java code.\n - For migration PRs: Only Flutter team members may migrate an existing plugin's Java code\n to Kotlin, due to the potential difficulty of reviewing such PRs; migration\n PRs from non-team members will be rejected. |
There was a problem hiding this comment.
This bothered me slightly when writing it, but I didn't (and don't) think it's worth adding nesting to the list just to avoid.
Change the policy for flutter/packages to prefer Kotlin rather than Java for new code, per RFC 720.0001
Part of #188630