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.

Sign up for GitHub

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

Jump to bottom

auto-value 1.10.2 breaks compatibility with Kotlin 1.6 #1574

Closed
breun opened this issue Aug 14, 2023 · 8 comments · May be fixed by #1575
Closed

auto-value 1.10.2 breaks compatibility with Kotlin 1.6 #1574

breun opened this issue Aug 14, 2023 · 8 comments · May be fixed by #1575
Assignees
@eamonnmcmanus
Labels
Component: value P3 Status: accepted type=defect Bug, not working as expected

Comments

@breun
Copy link

breun commented Aug 14, 2023 •
edited

Upgrading auto-value from 1.10.1 to 1.10.2 in a Kotlin 1.6 project results in:

[ERROR] /path/to/.m2/repository/com/google/auto/value/auto-value/1.10.2/auto-value-1.10.2.jar!/META-INF/kotlin-stdlib-common.kotlin_module: (-1, -1) Module was compiled with an incompatible version of Kotlin. The binary version of its metadata is 1.8.0, expected version is 1.6.0.

The auto-value 1.10.2 release notes don't mention any Kotlin compatibility changes, but compared to version 1.10.1 compatibility with Kotlin 1.6 and 1.7 was broken.

  • auto-value 1.10.1 uses kotlinx-metadata-jvm 0.5.0, which uses kotlin-stdlib 1.7.0
  • auto-value 1.10.2 uses kotlinx-metadata-jvm 0.6.2, which uses kotlin-stdlib 1.8.0
  • auto-value HEAD-SNAPSHOT uses kotlinx-metadata-jvm 0.7.0, which uses kotlin-stdlib 1.9.0

Was compatibility with older Kotlin versions broken intentionally or accidentally?
@breun breun mentioned this issue Aug 14, 2023
Closed
@breun
Copy link
Author

breun commented Aug 14, 2023 •
edited

This backwards incompatible change indirectly caused Google Cloud BigQuery 2.31.0+ (google-cloud-bom 0.201.0+, libraries-bom 26.20.0+) and Spring Cloud GCP 3.6.1+ to break compatibility with Kotlin 1.6 and 1.7: GoogleCloudPlatform/spring-cloud-gcp#2122 (includes a link to a sample reproduction project)

@chaoren chaoren added type=defect Bug, not working as expected P1 labels Aug 14, 2023
@chaoren
Copy link
Member

chaoren commented Aug 14, 2023

The kotlinx-metadata-jvm update happened automatically via @dependabot so it definitely wasn't intentional. @eamonnmcmanus how much do we care about old Kotlin versions? Would it be worthwhile to rollback the kotlinx-metadata-jvm updates?

@chaoren
Copy link
Member

chaoren commented Aug 14, 2023

kotlinx-metadata-jvm 0.6.2 is required for Kotlin 1.9 support though. I don't think we want to drop support for the latest Kotlin version to support Kotlin 1.6.

@chaoren chaoren added P3 and removed P2 labels Aug 14, 2023
@eamonnmcmanus
Copy link
Member

I think there might be some subtlety here. If we use an old version of kotlinx-metadata-jvm, then will it be able to introspect the metadata from classes compiled with a more recent compiler? I gather version N can read the metadata from version N+1 but not necessarily N+2.

(I see @chaoren brought up essentially the same question.)

I'm not sure what the right solution is. Perhaps make the kotlinx-metadata-jvm dependency <scope>provided or <optional>true, so that it can be resolved to whatever the rest of the application is using? In that case we'd have to rewrite all the code using these imports so it goes through reflection, and behaves sensibly when the metadata classes aren't available.

@eamonnmcmanus
Copy link
Member

Actually, if we do rewrite the metadata client code to use reflection, there's probably no reason to declare any sort of dependency on kotlinx-metadata-jvm. It will probably already be there if you're interacting with Kotlin data classes (which is what this is for), and if its API is backward-compatible we will find the right version to use and be able to use it.

I'll look into this possibility.

@copybara-service copybara-service bot mentioned this issue Aug 14, 2023
Open
copybara-service bot pushed a commit that referenced this issue Aug 14, 2023
@eamonnmcmanus
Access the Kotlin metadata API through reflection.
f8f0dec 
This means we don't need a dependency on that API when building AutoValue. Therefore users can freely supply the version of the API that corresponds to the actual Kotlin version they are using. The downside is that they may need to add that dependency explicitly when previously they were getting it through AutoValue. (But possibly getting the wrong version.)

Fixes #1574.

RELNOTES=AutoValue no longer has an explicit dependency on the Kotlin Metadata API. **You may need to add an explicit dependency on `org.jetbrains.kotlinx:kotlinx-metadata-jvm.** The reason for this change is to avoid problems that occurred when the version of the API that AutoValue bundles was different from the version that the user code expected. See #1574.
PiperOrigin-RevId: 556951184
@breun breun mentioned this issue Aug 15, 2023
Closed
@eamonnmcmanus
Copy link
Member

eamonnmcmanus commented Aug 15, 2023 •
edited

I did do the rewrite using reflection, but then realized that it isn't necessary. Many thanks to @breun for putting together the repro project. With that, I looked more closely at the error messages. As already noted in the original issue text, they look like this:

[ERROR] /path/to/.m2/repository/com/google/auto/value/auto-value/1.10.2/auto-value-1.10.2.jar!
/META-INF/kotlin-stdlib-common.kotlin_module: (-1, -1)
Module was compiled with an incompatible version of Kotlin.
The binary version of its metadata is 1.8.0, expected version is 1.6.0.

The issue is not with the copy of kotlinx-metadata-jvm (etc) in auto-value-1.10.2.jar. That is shaded, which means that the concerns I brought up in my earlier comment aren't real. The shading means that we can absolutely use the latest version of kotlinx-metadata-jvm without interfering with an earlier version that client code might be using. We just have to remove all the META-INF/*.kotlin_module entries from the jar. With that change, the repro project builds fine.

I'll look into getting a release out with that change in it shortly.

@copybara-service copybara-service bot mentioned this issue Aug 15, 2023
Closed
copybara-service bot pushed a commit that referenced this issue Aug 15, 2023
@eamonnmcmanus
Remove META-INF/*.kotlin_module entries from the AutoValue jar.
9808c4e 
We bundle a shaded copy of `kotlinx.metadata.jvm` and related libraries, which we use to inspect Kotlin data classes. The libraries are only called from Java code, which means that `META-INF/kotlinx-metadata-jvm.kotlin_module` and the like serve no purpose, other than to confuse the Kotlin compiler when it sees these entries.

Fixes #1574.

RELNOTES=An "incompatible version" issue with Kotlin compilation has been fixed. See #1574.
PiperOrigin-RevId: 557180357
copybara-service bot pushed a commit that referenced this issue Aug 15, 2023
@eamonnmcmanus
Remove META-INF/*.kotlin_module entries from the AutoValue jar.
3317f71 
We bundle a shaded copy of `kotlinx.metadata.jvm` and related libraries, which we use to inspect Kotlin data classes. The libraries are only called from Java code, which means that `META-INF/kotlinx-metadata-jvm.kotlin_module` and the like serve no purpose, other than to confuse the Kotlin compiler when it sees these entries.

Fixes #1574.

RELNOTES=An "incompatible version" issue with Kotlin compilation has been fixed. See #1574.
PiperOrigin-RevId: 557180357
@eamonnmcmanus
Copy link
Member

The newly-released 1.10.3 should fix this problem. Please let me know if not.

@breun
Copy link
Author

breun commented Aug 15, 2023

Thanks for the quick fix and release, 1.10.3 indeed seems to fix this issue. 👍

@breun breun changed the title auto-value 1.10.2 breaks compatibility with Kotlin 1.6 and 1.7 auto-value 1.10.2 breaks compatibility with Kotlin 1.6 Aug 16, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@eamonnmcmanus eamonnmcmanus

Labels
Component: value P3 Status: accepted type=defect Bug, not working as expected
Projects
None yet
Milestone
No milestone
3 participants
@breun @eamonnmcmanus @chaoren