Use kotlin.jvm annotations if jvmInterop #3502
Open
+28
−30
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Collaborator
Author
|
Okay looking at that failure, sorry. I have |
oldergod
approved these changes
Jan 21, 2026
wire-kotlin-generator/src/main/java/com/squareup/wire/kotlin/KotlinGenerator.kt
Outdated
Show resolved
Hide resolved
cbrunsdon
force-pushed
the
kotlin_jvm_annotations_on_jvm_interop
branch
from
35f6be9 to
b10aaa5
Compare
*Most* places were guarded in an:
```
if (javaInterOp) {
propertyBuilder.jvmField()
}
```
But the adapter and a few choice places were not.
Doing this with the boolean adds a bit of readability to these calls, as
it wasn't very clear if it was expected or accidental with the changes
to javaInterop checking before.
*Theoretically* we could remove these annotations in these places, but
they're required for things like the GSON generator that references the
ClassName#Adapater, so not now.
Again, not entirely sure the context of why this is always a jvm field, but we're going to explicitly leave it
I don't quite know the context of the android creator, but it was always added previously so leaving it so.
These can be moved pretty cleanly one-to-one with what was there before.
Everything moved over now, removing the old one.
I think the theoretical reason for needing the `internal.Jvm*` annotations is someone could choose to generate files outside of a common*/jvm*/main src directory, which wouldn't have the kotlin.jvm annotations defined. However, if javaInterop is requested, use the kotlin annotations instead. This works better in Some Places(tm) where other things care about those annotations that some nerds might care about. Like maybe some lunatic who depends on an included gradle project mixing both kotlin multiplatform and not...
Like @JvmField before, *if* we're building with JavaInterop we don't need the internal as we can be Quite Sure we're building into an environment kotlin will provide these annotations to us.
Doing these at the end for clarity, though the previous versions are still all valid against the previous commits.
Just something that is nice to know if you're reading this.
cbrunsdon
force-pushed
the
kotlin_jvm_annotations_on_jvm_interop
branch
from
b10aaa5 to
6c95693
Compare
buildersOnly will set javaInterOp = true, which *could* be set by someone that building in an enviroment that included `kotlin.jvm`. We'll still use the internal jvm* flags, though they can't get any use out of the @jvm* functionality.
Explicitely separating from the last commit, the constructor is private so this should be fine, with the `synthetic` there.
Feedback request on the PR.
cbrunsdon
force-pushed
the
kotlin_jvm_annotations_on_jvm_interop
branch
from
6c95693 to
3cf40aa
Compare
Collaborator
Author
|
Okay, I updated the inline annotations and pushed the "which package" decision up, due to The one thing I'd draw attention to due to unfamiliarity is I had to remove I think that sample is pretty contrived and old enough its probably not something someone would need to care about. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There is a bit of background around the
internal.Jvm*annotations here for background:#2504
They have two (minor?) issues:
@Jvm*are treated special, and certain setups of module dependencies and project layouts can cause IDE auto-completion, for instance, to not interpret theinternal.Jvmcorrectly, redlining your perfectly-reasonable and runnable codeinternalbut they're public aliases which isn't amazing to ship to any projects including wire-runtime and other careless programmers (totally not me though...) might accidentally auto-complete those in instead of their expected@Jvmannotations.I don't actually quite follow the how/when/why the
internal.Jvm*was required. It might be a historical issue that generating into /main wouldn't have those provided? That no longer seems to be the case as settingjvmAnnotationPackagein this commit to kotlin.jvm seems to run the suites just fine?This change sets the annotations to reference the
kotlin.jvmannotations if jvmInterop is enabled, which we should expect to be provided by anyone generating while explicitly asking for jvm compatibility.Either way, though this adds complexity to the generation process, I personally believe its worth it as a step to phase these out.