Figure out when to require Java 11 for new Guava versions

[cpovirk]

Probably not soon :) I just had another note I wanted to make about this, so now seems like the time to start collecting those notes.

• Since we're a dependency of so many other libraries (including ecosystems like Google Cloud), we aren't likely to drop support for Java 8 until such libraries do. Hopefully they won't take too long, given the relatively small amount of support provided for Java 8 nowadays from libraries and JDK vendors.
• Merely requiring a newer javac to build Guava could bring us some of the advantages of this without most of the downsides.
• But it would be even more convenient not to have to put Java 9+ features behind runtime checks of any kind.
  • [edit: also for VarHandle and for ProcessHandle in From Guava 32.0.1-jre, Files.createTempDir() and FileBackedOutputStream can fail or create un-deletable directories/files when used from a Windows service #6634]
• And it might eventually be nice to be able to put Java 9+ APIs (or other language features) in our public API. (We can't do that today, even with multi-release jars [edit: well, at least not without isolating any such new APIs to separate classes].)

[cpovirk]

I think I failed to actually mention the new "note I wanted to make about this," which was:

• JDK 8 has a bug in its reflection implementation, which we'd trigger if we omitted our checker-qual dependency. Granted, we can always decide to omit that dependency anyway, hurting JDK8 users who perform reflection on Guava types (and don't make checker-qual available themselves) but not hurting typical JDK8 users. That's in contrast to dropping Java 8 support, which of course would hurt all JDK8 users :)

[cpovirk]

It turns out that the latest release of jsinterop-annotations is built to require Java 11. That said:

• We somehow don't declare a dep on that library, even though we use things from that package in guava-gwt. Are we relying on users to provide it themselves? (This is another case in which it would be nice for our external GWT tests to be as thorough as our internal ones: b/169936479.) Ah, might the GWT plugin provide it automatically? Are the effects any different on J2CL than on GWT? (Perhaps J2CL users are even more likely to provide the dependency themselves?)
• I don't know how much the annotations artifact changes over time. I guess @JsNonNull was new in 2.0 or so, but I haven't looked at what changes in 2.1.0. Maybe we can get away with not updating for a while.
• Even if we eventually need to require Java 11 for this reason, we might be able to require it only for guava-gwt.
• Maybe things actually kinda sorta work if only annotations are built for Java 11, given how Java is usually tolerant of missing annotations?
• Oh, and this is all just in sources seen only by the GWT and J2CL compilers. Maybe we should just increase the -target for our GWT build? Unfortunately, I think that might affect both client (JavaScript) and server (bytecode), which would mean that users do need to upgrade. Hmm, I thought guava-gwt contained actual compiled classes (not just sources to be compiled by the GWT/J2CL compiler later), but maybe that is only for GWT-RPC, which we don't support anymore. If we do still need to provide server sources, perhaps it's possible to compile them with a different -target than the others.
• Or I guess we don't even need to change our -target: We just need to use a compiler that would recognize the newer bytecode (assuming that everything works OK for users at runtime). That's more like Require Java 11+ to *build* Guava but continue to support Java 8 at runtime #6549. I'll note this there.

[cpovirk]

Java 11 brought nestmates, which would let us make fields like this one private without any performance hit from the need for bridge methods. That hit is likely to be unnoticeable for most methods, small even for CharMatcher, and avoidable by assigning the result of the CharMatcher accessor call to a field (rather than calling the accessor over and over). Still, it would be nice for a single innocent-looking keyword not to have the potential to affect performance. And making things private is nice. (It's even required for similar constructs in Kotlin.)

Admittedly, making nested classes' members private is less important when the class that the API is part of is final, since that makes clear that any package-private methods aren't being called more widely through a subtype. And there are additional arguments for omitting private: One is that private doesn't further restrict visibility, so we'd rather write leave it out for brevity. Another (somewhat contradictory) argument is that the lack of private hints that the API is being used from the nested class's enclosing class (though of course Java would permit the call even with private, just with the possible performance hit discussed above).

Anyway, the point here is that we'd pick up this improvement (and others, like better string concatenation) if we didn't have to target Java 8. (Hmm, I guess we could theoretically provide a multi-release jar with the exact same classes built for both versions, just with different -source -target flags! This would even provide yet another partial defense against problems like that from #3990. But that would double the size of Guava (and possibly upset tools that get confused by mrjars) for very little upside.)

(I was tempted to add that we could consider targeting a newer version of Java for guava-android, since newer bytecode gets converted to Android bytecode that supports even old versions of Android. But of course we say that guava-android is usable under a JVM, too, so that wouldn't work.)

[cpovirk]

Other potentially nice things for the future:

• @Deprecated(forRemoval = true)
• the ability to drop a boatload of code in Throwables (including references to ThreadDeath, which is (speaking of which!) deprecated for removal), in ChecksumhashFunction, in Hashing, and perhaps elsewhere
  • [edit: I think we could actually remove a bunch of that code even now, since we already build with newer versions of javac.]
• we hope someday nullness markers
• var, pattern-matching instanceof (Java 16+), records (Java 16+, maybe even in our API somewhere), and probably other nice things
• [edit: Runtime.version, mostly for use in our tests, though we primarily check isJava8(), so any checks based on Java 8 would just go away entirely :)]
• [edit: System.Logger has come up before]
• [edit: SequencedCollection, Java 21+]
• [edit: Maybe hypothetically someday JDK-8072840 for pre-sizing for our Collector implementations. (hat tip to fmeum)]
• [edit: Omitting enclosing-instance fields from inner classes that don't use them, Java 18+]

(As always, we'd want to keep in mind that we also still target Android, including fairly old versions, so we might not want to make at least some changes until we can make them there, too.)

[cpovirk]

Java 11 brought nestmates, which would let us make fields like this one private without any performance hit from the need for bridge methods.... And making things private is nice. (It's even required for similar constructs in Kotlin.)

I learned yesterday that nestmates also enable runtime access through MethodHandles.Lookup, which would be helpful for the forthcoming usage of VarHandle in AbstractFuture (and, I suspect, would let us simplify its existing usage of AtomicReferenceFieldUpdater) in #7555. We have an easy workaround, but it would have been nice to not have had to fiddle around with the code and then retrace my steps after I forgot my earlier partial understanding and so had to build up a fuller understanding later.

[cpovirk]

More notes:

Historically, one reason that we've maintained support for Java 8 is the Google Cloud Client Libraries. The documentation for those libraries currently says:

Java 8 will continue to be supported by Cloud Client Libraries for Java until at least September 2026.

I'm not sure how much we've pushed on the idea that those libraries could stick with an older version of Guava if Guava were to drop support for Java 8 before Cloud did. I would expect that approach to work well in practice for Cloud users, but I could imagine that some users would have reservations about running with a newer version of Guava than the one that Cloud recommends, and that may be enough to stop the idea.

Anyway, the reason that I'm thinking about this yet again is that the majority of my week is going to reworking our nullness annotations to work better with Java 8 (e.g., #7566). That's turned what should have been a straightforward update of https://github.com/google/guava/tree/jspecify-preview into a Project.

[cpovirk]

Whenever we do do this, Cloud (and others) may want us to bump our major version. It's left a bit up in the air in https://opensource.google/documentation/policies/library-breaking-change. Additionally, that policy refers to "vendor support," which can mean a lot of things in the context of Java (and something else in the context of Cloud). It's something for us to look into.

[kevinb9n]

I see a variety of "implementationy" advantages, but the bigger issue is that Guava public APIs are unable to reference any new library types, so they're unable to provide the best level of service to clients who are on the newer versions. SequencedCollection is a fine enough example of this.

I suspect that mr-jars aren't going to be an easy way out of this. It would be useful if we could push on "okay, what does happen if Guava 34.0 requires Java 21 (or even 17, or even 11)?"

There has to be a solution that involves certain users and certain ecosystems simply getting pinned to Guava 33 for a while and living with the pain of that. Otherwise, how would it ever be possible?

Does anyone at G feel like fleshing out that picture?

[cpovirk]

My feeling has been that the API needs just haven't been that big. SequencedCollection is fine but hasn't felt compelling on its own. Nullness markers would of course get me to reconsider very quickly, despite the downsides to users stuck on older versions :)

For pure additions, we also have the option to put whatever we want in another class: There's nothing to stop us from adding com.google.common.base.Records today with getCanonicalConstructor or whatever; what would get us in trouble is "only" additions/changes to existing classes.

I hope to have a better picture of what users want as Google and other Guava users continue to get experience with Java 21 and higher.