Require Java 11+ to *build* Guava but continue to support Java 8 at runtime

[cpovirk]

I'd mentioned this in #3990 (comment).

It would be nice to be able to refer in source code to newer types (e.g., CRC32C, VarHandle, and @ReservedStackAccess)—with, of course, appropriate runtime guards. Of course, that would be incompatible with one of the possible approaches to #3990, which is to use --release.

(Using Java 11 might also still dodge bugs in older versions of javac. [edit: another one])

We'd probably accept a PR for this unless some of our users want to tell us that they build Guava from source themselves with javac 8 (or 9 or 10), in which case the decision would get more complex.

[cpovirk]

Of course, that would be incompatible with one of the possible approaches to #3990, which is to use --release.

Well, not completely: We could use --release 8 but then perform a second compilation with (e.g.) --release 11 to put a second set of classes into a multi-release jar. Even though multi-release jars don't do one of the things we might like, I think they could work well here. We could even imagine conditionally using APIs like CRC32C internally by providing an exception-throwing implementation for Java 8 in addition to a "real" implementation for newer versions and then making sure to perform appropriate checks before using the implementation class.

[ben-manes]

@ReservedStackAccess is only available to privileged code during bootstrap and be ignored otherwise, unless -XX:-RestrictReservedStack is specified. Similarly for @Contended and its flag -XX:-RestrictContended. That unfortunately makes it useless for library code.

It may be reasonable to use Atomic*FieldUpdaters instead of Unsafe. When introduced in Java 5 they were known to have performance issues. That may be mostly resolved according to Faster Atomic*FieldUpdaters for Everyone. You might consider running a fresh set of benchmarks on those usages to see if the impact is acceptable.

I would be inclined to instead make jdk11 the minimum version. Those who are performance sensitive should not be on jdk8 and those users are likely to only need critical bug fixes to be backported. Android annoyingly only supports a subset of jdk11, but likely enough for your needs. You'll certainly have people complain but external are suffering regardless and internal are posing a security risk, so you might not have as much actionable push back if pursued.

I recall some tools were not multi-release jar friendly (e.g. if naively creating a fatjar) and since they are not widely used, I'd consider that to likely be a higher risk of unexpectedly breaking someone in a surprising way than adopting jdk11.

[cpovirk]

Thanks, I'm not sure whether I ever knew that about the annotations. I'll have to dig up some past threads and leave a link from them to here.

I'll also read your link about the field updaters. That's good news for someday getting off Unsafe.

As for requiring a new Java version, that is above my pay grade :) Thankfully, even our final straggler internally was moved off Java 8 a while back, but we'll likely need to maintain compatibility as long as enough open-source Google and non-Google libraries do.

Sadly, if we try to make only bug fixes to a Java 8 backport, I'd expect the same kind of version conflicts that users are used to from the days when we often removed APIs: If one of your deps updates to Guava 32.4.0, then it might use APIs that aren't available to you.

It's good to know that we should look into the fat-jar situation if we try mrjars. I think we had some trouble with that kind of thing internally, if I'm remembering right. Hopefully it's been sorted out both internally and externally, but it's worth remembering that there are risks to everything (just in case the recent CVE-Windows experience didn't remind me enough :)). And at the moment, the benefits of using Java 9+ APIs are looking small (especially after what you said about the annotations), so we will have less motivation to go with a multi-release jar (though it's still a possibility).

--

One other note that I should have put in my original post:

Also related to toolchains: #5457 That's where I'd previously mentioned google/error-prone#3895 (comment), which is the key to testing Java 8 compatibility even when building with a newer version.

[cpovirk]

My guess at the full set of related commits in Error Prone is:

• google/error-prone@047e1e3
• google/error-prone@020a541
• google/error-prone@c2b71f9