urgh: ```error in project :B Cannot inline bytecode built with JVM target 11 into bytecode that is b...

# gradle

[groostav]

urgh:

error in project :B
Cannot inline bytecode built with JVM target 11 into bytecode that is being built with JVM target 1.6. Please specify proper '-jvm-target' option

I have a ~simple gradle.build.kts with two projects (:A and :B, where B depends on A with a deps{compile(project(":A"))}), and about 20 runtime deps.
1. under intelliJ i can verify that the output class files from :A are in java 11 (bytecode v55)
2. when i omit my problem section and compile :B without it, I get java 11 (bytecode v55) classes
I'm using

tasks.compileJava {
    options.release.set(11)
    sourceCompatibility = "11"
    targetCompatibility = "11"
}
tasks.compileKotlin {
    kotlinOptions.jvmTarget = "11"
    sourceCompatibility = "11"
}

everywhere I can think.

help?

[ephemient]

don't configure just individual tasks, configure all tasks https://youtrack.jetbrains.com/issue/KT-17078

java {
    sourceCompatibility = "11"
    targetCompatibility = "11"
}
tasks.withType<org.jetbrains.kotlin.gradle.tasks.KotlinCompile>().configureEach {
    kotlinOptions.jvmTarget = "11"
}

[ephemient]

also Kotlin doesn't support --release https://youtrack.jetbrains.com/issue/KT-29974

[tapchicoma]

I wonder where you get this JVM 1.6 bytecode, cause Kotlin, by default, sets target to 1.8. Could you paste here output of running: ./gradlew :a:outgoingVariants

[ephemient]

default since Kotlin 1.5, was 1.6 in Kotlin 1.4 and earlier

[tapchicoma]

ah, that could be also an option

[groostav]

thanks guys, the errors i mention are from intellij, when i run from the command line im getting different behaviour

[groostav]

i am also explicitly using kt 1.4 and not 1.5 because I havent yet updated our tooling on to 1.5

[groostav]

though i do also have a copy of the stdlib 1.5 ( a kopy?) sneaking around on my classpath, not sure where its coming from

[tapchicoma]

it could come from Gradle Kotlin runtime, but should be only in build classpath

[tapchicoma]

are you building with Intellij Build system or delegate it to Gradle?

[ephemient]

could be coming from a dependency, since you definitely have some that are targeting newer jvm

[groostav]

ok so @ephemient your suggestion nailed it, using tasks.kotlinCompileTasks.configEach { ... (as opposed to tasks.kotlinCompileCollection { ... ) solved the issue

[tapchicoma]

generally I would advice you to migrate to Kotlin 1.5.31 and use Gradle JVM toolchain feature to avoid such problems

[groostav]

I had always assumed that gradle, being groovy like, would try to sort've map your configuration across the collection, so the gradle code `someCollectionOfTypeAs.configTypeA()`would be synonamous with someCollectionOfTypeAs.forEach { it.configTypeA(), is that not true?

[ephemient]

note that I also suggest using the top-level java extension and not configuring an individual JavaCompile task

[groostav]

as in java { target = 11 } instead of tasks.compileJava { target = 11?

[ephemient]

no it's not, not in Groovy DSL nor Kotlin DSL does configuring one task affect others

[groostav]

also @tapchicoma ill google gradle jvm tool chain

[ephemient]

yes

[ephemient]

https://youtrack.jetbrains.com/issue/KT-15370 hopefully in the future it'll be possible to configure Kotlin similarly

[tapchicoma]

Kotlin 1.5.31 adds a check that related Java - Kotlin tasks has the same jvm target

[tapchicoma]

in the future it'll be possible to configure Kotlin similarly

Most probably from Kotlin 1.7 😉

[ephemient]

there's also some automatic logic that picks up the target, but it only works with the project-level Java extension IIRC

[ephemient]

if you're targeting Android, toolchains aren't usable yet, but in all other cases they're great

[groostav]

no it's not, not in Groovy DSL nor Kotlin DSL does configuring one task affect others

sorry, even though the type of tasks.withType<S>() is TaskCollection<S> , you mean to say that
TaskCollection<S>.invoke(config: S.() -> Unit)
does not do the same thing as
TaskCollection<S>.configureEach(config: S.() -> Unit)
?

[groostav]

also, can i get gradle to print my tree of maven dependencies? calling `gradle -q dependencies`doesnt print out any of my maven deps

[groostav]

ahh never mind, i just needed to specify the project;
gradle -q :api:dependencies

[groostav]

thanks @ephemient and @tapchicoma so much for your help, i rip my hair out with this stuff pretty regularly.

[ephemient]

tasks.kotlinCompile is a single task, not a collection
tasks.kotlinCompile { ... } configures that single task
tasks.withType<> { ... } is not TaskCollection.invoke, it is a legacy eager API
tasks.withType<>().configureEach { ... } is what you should use to configure all tasks

[groostav]

thats pretty scary

[ephemient]

it is documented, https://docs.gradle.org/current/userguide/task_configuration_avoidance.html#sec:old_vs_new_configuration_api_overview

[ephemient]

hopefully in the future Gradle can introduce some mode to make it more visible when you're doing something you shouldn't be https://github.com/gradle/gradle/issues/16344