Compilation error with Kakao new version 3.5.0

[tasomaniac]

There is a difference between the JDK being used to build the library vs the "target" it is set to. The best practice is to set the JDK to the most up to date to get compiler benefits. But the target is better to be set at a minimum level to increase compatibility. This is similar to libraries setting Android minSdk to 21 or 23. Most Kotlin libraries are set to 11.

I see in this PR from before that 2 things are updated together:

• JDK that is used in the CI: https://github.com/KakaoCup/Kakao/pull/105/files#diff-1da7a27709d11ac16eef3de8e46ed10672b7b1d63a790ffbcbd23a94b19efdcbR24
• JVM Target: https://github.com/KakaoCup/Kakao/pull/105/files#diff-367321b2f284ceade658bdabfb5640b75f96629be4f94f3a467f7753102a4c91R15

2nd one is not needed and it creates the below incompatibility.

Steps to reproduce:

1. Just update the version
2. Compile/assemble test build

Observed Results:

The following error is observed

e: ScreenExtensions.kt:33:12 Cannot inline bytecode built with JVM target 17 into bytecode that is being built with JVM target 11. Please specify proper '-jvm-target' option

Expected Results:

Compile just fine when the host app targets JVM 11

[Vacxe]

@tasomaniac unfortunately here is technical difference between minSdk and tooling versions. minSdk is supportive parameter, but keeping build tooling up to date is a technical debt in project.

https://developer.android.com/build/releases/gradle-plugin

Regarding to android gradle plugin documentation you follow this compatibility map

For Kakao we trying to maintain out debt and support all latest versions as we can, because migration between minor versions is much easier then from example Gradle 4 -> 8.

If you want to use latest library version you may migrate you project to the latest tooling set as well

We don't have plans to roll back to gradle 8.3 and Java 11

[tasomaniac]

Maybe you got me wrong. I was giving an analogy. You can use all the latest tools in your project. You can even use JDK 21 (much newer than 11). But you don't have to change the target version. If you do change it, you force your users of the library to go up too. You can still use whatever Java version and Android version internally but keep the compatibility to a lower number. This is actually how most libraries do including Google's AndroidX project etc.

[Vacxe]

Sorry mate @tasomaniac I still didn't get a point what exactly you want to change without rolling back to previous tooling versions. Please raise a Pull Request with proposal changes.

[tasomaniac]

That's alright. I opened this up to understand if this behavioral change was intentional because we cannot update anymore

I will open a PR with perhaps a failing repro project. Just need to find some time

[Vacxe]

@tasomaniac I've tried many other options to make it run with 11 java compatibility, unfortunately with no results