Closed psx95 closed 2 months ago
@punya any concerns about not actually testing against Java8? @psx95 mentioned that we weren't doing it before either so this seems reasonable. But I'm no Java expert and don't know what might go wrong
I think the ideal way going forward would be to write a CI that loads the modules/JAR intended to be distributed as Java8 compatible on a VM that only has Java 8 installed on it.
I don't think we should force the current unit tests to use Java8 API.
What might go wrong?
A bump in gradle version or some gradle config changes could cause the --release
flag to be ignored, resulting in artifacts that are not Java 8 compatible.
Edit: This would not have been a concern if were using two different JVM toolchains (Java 8 for all projects and Java 11 for e2e-tests). I had previously considered this way, but changed the implementation due to the following reasons:
We're lucky that we hardly took any dependencies on new syntax or libraries in all this time!
Yes! Most of the new syntax is used only in unit tests - https://github.com/GoogleCloudPlatform/opentelemetry-operations-java/pull/353/commits/cfa27e5bc36a543a54e1edf18ebf30ca332db145.
Description
This PR makes the minimum supported version for artifacts generated from this repository to Java 8 by default. Operational modules like
e2e-testing
, may use higher Java versions due to dependency constraints.Testing
./gradlew clean build
successfully runsjavap -v path/to/classfile/in/jar
reveals major version as 52 (Java 8) and 55 (Java 11) for expected modules.