Figure out when to drop Java 8 support

[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.
• 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.)

[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 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 https://github.com/google/guava/issues/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 https://github.com/google/guava/issues/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.)