stupid question, if I define `targetCompatiblity` ...

# announcements

[robstoll]

stupid question, if I define targetCompatiblity in my build.gradle to be 8 but do not define kotlinOptions.jvmTarget to be 1.8, so it should be 1.6 per default, what is the compiler supposed to generate?
I am asking because I came across java.util.function.Consumer in the resulting byte code and this one was introduced in 1.8

[ilya.gorbunov]

Kotlin compiler generates bytecode taking into account solely jvmTarget option value, so if it's 1.6, then the resulting bytecode will be compatible with JVM 1.6.
You can meet j.u.function.Consumer type in the compiled code, however, if you use JDK 1.8 or greater in the compile classpath and use API either from that JDK or other java dependencies that takes it as a parameter. The path to JDK can be overridden with jdkHome option.

[Shawn]

where do sourceCompatibility and targetCompatibility come into play then? I’ve seen them in various build.gradle[.kts] files, but if kotlinc only cares about jvmTarget then how did we get these extraneous properties?

[ilya.gorbunov]

They affect java code compilation. Perhaps, they are generated by a wizard or are copy-pasted from somewhere.

[robstoll]

@ilya.gorbunov So I should file a bug right? I am not using j.u.function.Consumer directly and I can see it in my jar not in the jdk8 jar

[ilya.gorbunov]

Where do you see it? Is it some Java API call?

[robstoll]

sorry, false alarm. I just dug deeper and saw that it's not in the resulting byte code kotlin generates

[robstoll]

ok, false alarm of the false alarm 😄
I could not see it in the kotlin byte code viewer but it is there in the jar file

[robstoll]

and no, no java call is made.

[robstoll]

the corresponding code is this one
https://github.com/robstoll/atrium/blob/master/core/api/atrium-core-api-common/src/main/kotlin/ch/tutteli/atrium/core/polyfills/loadService.kt#L29

[robstoll]

and the resulting class file

LoadServiceKt$useSingleService$1$1.class

[robstoll]

and this one contains: java/util/function/Consumer<TT;>

[robstoll]

but maybe don't spend time yet. Since you mention it should not be the case it could also be that there is a problem in the project setup and jvmTarget is set somewhere to 1.8

[robstoll]

afterEvaluate {
    println("kotlin jvmTarget: " + compileKotlin.kotlinOptions.jvmTarget)
}

kotlin jvmTarget: 1.6

Shall I file a bug?

[ilya.gorbunov]

It looks like JDK's forEachRemaining iterator member function is used instead of the imported extension ch.tutteli.kbox.forEachRemaining.

[ilya.gorbunov]

Note that jvmTarget option affects what bytecode version is produced by the compiler, not what subset of API is visible in the JDK. If you need your code being actually runnable on JVM 6, it makes sense to specify the path to JDK 6 to Kotlin compiler with the jdkHome compiler option.

[robstoll]

I see, shall I file a bug for not using the extension method?

[ilya.gorbunov]

Why is that a bug? Member wins over extension when both are applicable.

[robstoll]

well, there is a discrepancy between generated byte code and Kotlin byte code viewer. Also intellij does not show that jdk's method takes precedence. There is definitely a bug somewhere

[ilya.gorbunov]

This may be if IDEA uses different JDK than compiler. Could be some problem in project import then. That's sure worth reporting.