Library artifacts likely should not use Java 17 bytecode?

[bubenheimer]

Since version 6.0.0 the android-maps-utils library artifacts seem to use Java 17 bytecode. When using some of these APIs in a kotlin project targeting Java 11 I see:

Cannot inline bytecode built with JVM target 17 into bytecode that is being built with JVM target 11. Specify proper '-jvm-target' option.

I can raise my project target to Java 17 and it will build, and what I've tested did run on older Android versions, like Oreo or so, without desugaring, but I assume that I am losing certain compile time checks prohibiting newer Java language features, even if android-maps-utils works without those. For example Java runtime library APIs. The same trap would exist, I think, for other libraries that depend on this one, e.g. android-maps-compose.

This looks like an unintended oversight to me. android-maps-utils 7.0.0 supports Android API 24/Nougat, but Nougat does not support Java 17 features.

The option of desugaring adds another potential aspect here, but I don't think it squarely aligns with the issue at hand here. And I don't think that a utilities library should require an app to use desugaring unless it is central to its function somehow.

I may be missing something.

[bubenheimer]

I've tested it with Android 10 (Q), not Oreo, actually.

[3dagger]

The error comes from the Kotlin compiler, and it only concerns inline functions. kotlinc copies an inline function's bytecode into your module, and it refuses to copy bytecode built for JVM 17 into a module that targets JVM 11. Calls to non-inline functions in the library compile fine, which is why only some APIs trigger it. The 17 comes from the library's own build, which sets both the toolchain and the target to 17 (library/build.gradle.kts#L50-L56).

On losing compile-time checks: on Android, jvmTarget mostly picks the class-file format and which language features the compiler may emit. It doesn't decide which Java runtime APIs you can call.

• You compile against android.jar from compileSdk, not against the JDK 17 class library. Raising jvmTarget to 17 doesn't add any runtime API to your classpath.
• Whether an API exists at your minSdk is checked by Lint's NewApi check, and that check works the same at any jvmTarget. For example, java.time.LocalDate with minSdk 24 is still flagged unless you enable core library desugaring.
• Class files never reach the device. D8 converts them to DEX and desugars the language features, so code compiled for JVM 17 runs on API 24. That matches what you saw on Android 10.

So moving your module to 17 is safe on Android. Keep Java and Kotlin on the same target, or KGP's JVM target validation will fail the build:

android {
    compileOptions {
        sourceCompatibility = JavaVersion.VERSION_17
        targetCompatibility = JavaVersion.VERSION_17
    }
}
kotlin {
    compilerOptions { jvmTarget.set(JvmTarget.JVM_17) }
}

AGP 8+ already needs JDK 17 to run, so nothing changes on the build machine.

If some consumers really have to stay on 11, the library could keep jvmToolchain(17) and publish with jvmTarget = JVM_11 (and Java targetCompatibility 11). That's a fair request for the maintainers, but Android doesn't need it to run correctly.

[bubenheimer]

Thanks, @3dagger, I am capable of using AI. Consider using attribution.

[bubenheimer]

Also, there are omissions in the AI write-up. For example:

1. Once a library uses Java 17 bytecode there are no guarantees that it does not rely on Java 17 features, precluding it and its usages from working on lower Android versions.
2. Any library depending on this library in the manner that I described in the OP also ends up requiring Java 17.
3. Some Java runtime library dependencies are more subtle than others, and unlikely to be flagged: https://jakewharton.com/kotlins-jdk-release-compatibility-flag/

Moving a lib to Java 17 would seem to introduce significant stability concerns for its users.

And no more AI slop in this discussion, please.