Our Android project uses Java 8. Does Kotlin or compiling our project benefit at all if we upgrade t...

# android

[Nick]

Our Android project uses Java 8. Does Kotlin or compiling our project benefit at all if we upgrade to Java 11?

[Landry Norris]

I think if you target Java 11 on the Kotlin side, it will be able to optimize the byte code slightly more, but I can’t find a source on this anymore. Just vague memories.

[Nick]

If you want to make use of optimizations available in newer versions of Java, you can explicitly specify the target Java version from 9 to 19.

I see this from here, I wonder what optimizations there are?

[Landry Norris]

I’d imagine there’s more things that are guaranteed in a Java 11 runtime than a Java 8 runtime, as there’s more time for the runtime maintainers to implement changes.

[Landry Norris]

The latest new bytecode instruction to my knowledge is invokedynamic in Java 7.

[ephemient]

if your minSdk is not >= 26, d8 will desugar invokedynamic back to lambda classes anyway

[ephemient]

the biggest benefit IMO is being able to freely use newer libraries. you can't use an inline fun from a library that was built with Java 11 bytecode in a project that targets Java 8

[ephemient]

desugaring supports a growing number of Java 11 APIs as well, https://developer.android.com/studio/write/java11-minimal-support-table https://developer.android.com/studio/write/java11-default-support-table https://developer.android.com/studio/write/java11-nio-support-table

[Nick]

If we upgrade to Java 11, do we still need to desugar to get the java.time package?

[Nick]

sorry not really a kotlin question

[ephemient]

for Android, yes. there's a difference between the bytecode target and the APIs available at runtime

[ephemient]

but note that the desugared java.time is missing various localization features as compared the real implementation, due to limitations of older SDKs

[Nick]

Is there anything bad that could happen when we upgrade to java 11 from 8?

[Landry Norris]

Are you using any of the java.security functions? Those tend to be the main thing I see break when upgrading.

[Nick]

val hasher = MessageDigest.getInstance("SHA-256")
            val hash = hasher.digest(data.toByteArray(Charsets.UTF_8))
            return Base64.encodeToString(hash, Base64.NO_WRAP)

[Nick]

just that

[Landry Norris]

SHA-256 should be fine.

[ephemient]

on Android, those would break on SDK changes and not Java target changes anyway (https://developer.android.com/guide/topics/security/cryptography#deprecated-functionality)