Build with --release 8, or require builds to use JDK 8

[cpovirk]

I discovered in protocolbuffers/protobuf#7827 (comment) that Animal Sniffer does not fail the build for dangerous covariant return types. This means that, if we build a Guava release with JDK 11 (which we probably will, if we haven't already!), it will contain references that don't work under JDK 8. We do in fact have such references.

Luckily, I do not see any additional such problems in the Android branch. (Presumably our internal Android tests have detected any possible problems so far.)

We should set this up before our next release or else be VERY VERY sure to use JDK 8 to build it.

[cpovirk]

Later, assuming that the implementation of GoogleCloudPlatform/cloud-opensource-java#1605 goes in, we should consider switching to the Linkage Checker Enforcer Rule.

[cpovirk]

Ah, but the Linkage Checker will check only against the JDK that you're using to build. So we're back to needing to require builds to use JDK 8. And all the Linkage Checker would be doing then is looking at dependencies (of which we have effectively none).

[cpovirk]

--release 8 is indeed intended to catch such problems, including the specific ones we'd see with ByteBuffer: jetty/jetty.project#3244 (comment)

[cpovirk]

As I just noted on the protobuf thread, it sounds like the best option is to require builds to be done with JDK 8. (It might also be OK to build with a newer JDK but with an older bootclasspath, but I'm not sure how well supported that is, since bootclasspath is on the way out. I gather that we're internally doing something along those lines with Bazel, but I don't know how easy it is to do the equivalent externally or with Maven.)

We could consider requiring JDK 8 only for release builds. That would make life easier for an average developer who wants to contribute to Guava (and might not have JDK 8 lying around). On the other hand, it might make it more confusing to reproduce actual problems. Maybe we'd want to support some kind of -DletMeUseMyOwnJdkIPromiseIAmNotDoingARelease override flag.

Hmm, and we have Travis building with various versions.... I wonder how long it will be until openjdk8 is no longer available there.

[cpovirk]

(Certainly we at least want it to be possible to build and test with another JDK, since we want to verify that Guava works with new Java versions.)

[cpovirk]

Hmm, internally we're not going to be able to keep building with JDK 8 after our switchover. (And as established above, we can't just use --release.) So we should probably look at (a) wrapping all our calls to ByteBuffer methods that are changing and (b) writing a quick Error Prone check to ensure that we continue to do so.

Such a check, of course, would catch only the methods that we specifically program it to look for.

If we get things right internally, that should also make it possible to build with JDK 11 externally.

And building with JDK 11 is good for at least one more reason: Just as we currently use Unsafe conditionally, we'll want to use new APIs like VarHandle and @ReservedStackAccess conditionally. For that, we'll need to build with newer JDKs. It would be a shame not to have a way to make those improvements available publicly. [edit: Oh, but I guess that is what multi-release jars are for. We'd have to do some work to set them up, but it should be doable.]

We'll see if it's still straightforward to refer to Unsafe when building for JDK 11. Maybe we'll end up with a gross build setup that unpacks an old rt.jar and tries to put sun.misc.Unsafe on the classpath. Or maybe we'll end up running multiple separate javac invocations. Or maybe this will end up being easier under Bazel, since presumably external Bazel will support whatever we end up doing with internal Bazel. But if we're lucky, it will remain straightforward. [edit: Bazel still supports building with JDK8, but we might prefer not to rely on whatever build tools we use to support older JDKs for long.]

[cpovirk]

Hmm, and this is not the same thing, but when testing my fix for ByteBuffer when building with JDK 11, I noticed an error when running mvn clean install:

[ERROR] Failed to execute goal org.apache.maven.plugins:maven-javadoc-plugin:3.1.0:jar (attach-docs) on project guava: MavenReportException: Error while generating Javadoc: Unable to find javadoc command: The environment variable JAVA_HOME is not correctly set. -> [Help 1]

It works fine if I set JAVA_HOME, but it's unfortunate that that's necessary. I will see if 3.2.0 works better.