Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Kotlin: use Enum.entries instead of Enum.values() #2182

Merged
merged 5 commits into from
Jul 12, 2024

Conversation

jmartinesp
Copy link
Contributor

@jmartinesp jmartinesp commented Jul 8, 2024

Since Kotlin 1.9, the .entries property is generated at build time for enum classes. Unlike Enum.values(), this property doesn't instantiate a new array with every enum case every time it's used, instead a single List instance is reused.

This should improve performance a tiny bit for Kotlin bindings. However, note this will only be supported since Kotlin 1.9, I don't know if there is a min version the project wants to support.

@jmartinesp jmartinesp requested a review from a team as a code owner July 8, 2024 15:39
@jmartinesp jmartinesp requested review from badboy and removed request for a team July 8, 2024 15:39
@jmartinesp
Copy link
Contributor Author

The CI seems to fail because it uses Kotlin 1.8.20 or lower 😅

@jmartinesp jmartinesp force-pushed the kotlin/use-entries-for-enums branch from 9c5d17b to 08c7643 Compare July 12, 2024 16:56
…entries` usage on `Kotlin >= 1.9.0` and keep backwards compatibility with previous versions
@jmartinesp jmartinesp force-pushed the kotlin/use-entries-for-enums branch from 08c7643 to bd83dbe Compare July 12, 2024 16:57
@jmartinesp
Copy link
Contributor Author

I added an use_enum_entries config parameter to enable this change on Kotlin >= 1.9.0 while keeping backwards compatibility with previous versions of the language.

| `external_packages` | | A map of packages to be used for the specified external crates. The key is the Rust crate name, the value is the Kotlin package which will be used referring to types in that crate. See the [external types section of the manual](../udl/ext_types_external.md#kotlin)
| `android` | `false` | Used to toggle on Android specific optimizations
| `android_cleaner` | `android` | Use the [`android.system.SystemCleaner`](https://developer.android.com/reference/android/system/SystemCleaner) instead of [`java.lang.ref.Cleaner`](https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ref/Cleaner.html). Fallback in both instances is the one shipped with JNA.
| `use_enum_entries` | `false` | Uses `EnumClass.entries` instead of `EnumClass.values()` in the bindings, which is more efficient as it reuses the same list instance every time. Note this is only available since Kotlin 1.9.0
Copy link
Contributor

@bendk bendk Jul 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like the idea of using a config value for this a lot. My one concern is that we'll end up with tons of these entries that people will need to fiddle with. What do you think of adding something like kotlin_target_version? The use_enum_entries method can check if it's >= 1.9.0. This same logic could be re-used for using other language features.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A simple >= will only work if this is stored as a tuple though, not if it's stored as a string.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That sounds like a sensible idea. Let me check if I can get something working real quick.

Copy link
Contributor Author

@jmartinesp jmartinesp Jul 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great, my one last concern is the use of cargo_metadata for the parsing. We're working towards making that optional, so I'd rather we did the parsing ourselves.

However, this is getting really far away from your original concerns though. Do you want to try to tackle this or should we merge it as-is and I can try to handle that one as a follow-up?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'd rather merge it as is, if possible. I didn't realise you were trying to get rid of cargo metadata. Maybe I should have used semver instead?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good, let's merge this and figure out how to remove it later. I'm kind of thinking that we can just parse the versions by hand for now and avoid the extra dependency, but we can discuss in a separate PR.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oops, I see there's still a clippy error. I can merge once you fix that one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I hope 1dfd0a5 will fix it 🤞 .

@jmartinesp jmartinesp requested review from jplatte and bendk July 12, 2024 19:34
@jmartinesp jmartinesp force-pushed the kotlin/use-entries-for-enums branch from 486fa87 to 75a06ea Compare July 12, 2024 19:35
@bendk bendk enabled auto-merge July 12, 2024 20:47
@bendk bendk disabled auto-merge July 12, 2024 20:47
Copy link
Contributor

@bendk bendk left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks like that worked, thanks for the contribution.

@bendk bendk merged commit 037d825 into mozilla:main Jul 12, 2024
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants