okhttp icon indicating copy to clipboard operation
okhttp copied to clipboard

Ensure builds run with a specific JVM version

Open yschimke opened this issue 1 year ago • 3 comments

          > ```

e: file:///home/runner/work/okhttp/okhttp/okhttp/src/main/kotlin/okhttp3/OkHttpClient.kt:257:33 Type mismatch: inferred type is Long but Int was expected e: file:///home/runner/work/okhttp/okhttp/okhttp/src/main/kotlin/okhttp3/OkHttpClient.kt:615:27 Type mismatch: inferred type is Int but Long was expected e: file:///home/runner/work/okhttp/okhttp/okhttp/src/main/kotlin/okhttp3/OkHttpClient.kt:1298:22 Type mismatch: inferred type is Int but Long was expected e: file:///home/runner/work/okhttp/okhttp/okhttp/src/main/kotlin/okhttp3/OkHttpClient.kt:1326:24 Type mismatch: inferred type is Int but Long was expected

Thanks. I figured out the issue with gradle. I had my JVM set to Java 8. It works with Java 21.

Now these should be gone.

Originally posted by @ArloL in https://github.com/square/okhttp/issues/8189#issuecomment-1890454018

We should fail earlier with a clear message in these cases. Or maybe gradle has a way to cause that?

yschimke avatar Jan 13 '24 13:01 yschimke

Or even better, let’s configure Gradle to build on a consistent JVM, regardless of what your environment provides.

swankjesse avatar Mar 31 '24 15:03 swankjesse

https://jakewharton.com/gradle-toolchains-are-rarely-a-good-idea/

I guess if we bump this up high, like the latest LTS, it's not terrible?

yschimke avatar Apr 01 '24 18:04 yschimke

LTS releases are for JVM deployments where you are unable to upgrade for (mostly illogical) reasons. Aside from compatibility with build tooling, there's no reason not to use the latest JDK. The best LTS version is the latest version, as it's where security fixes and performance improvements land first.

JakeWharton avatar Apr 01 '24 18:04 JakeWharton