Build for Java 8 rather than Java 7.

[eamonnmcmanus]

Closes #2743.

[cpovirk]

A few notes, mostly, on the Android front:

• I see that you already have an Animal Sniffer check for Android compatibility. We seem to be getting good results in Guava from the https://github.com/open-toast/gummy-bears signatures that you mention, the ones that assume only the always-on desugaring of a smallish set of methods. Those are safe to use even if your users don't opt in to the more extensive feature that we normally refer to as "library desugaring," so you might have a look if javac starts generating usages of those methods automatically(?) or if you just want a smattering of Java 8 goodies.
• I don't see any issues with conditional support for Optional and Instant and friends. Once you've checked that the classes exist (see sub-bullet), you'll now be able to write normal Java code to operate on those classes. Android doesn't even mind if you have random methods in a class with Optional and Instant in the signature (in contrast to Java, which would, IIUC) as long as you don't call them.
  • I imagine the best way to guard that support will be with Java reflection that looks up those classes. I would hope that that would support both the case of Android versions new enough to support the classes directly and the case of desugaring (which I hope is smart enough to rewrite strings used in reflection). I have made the mistake before of just trying to use the classes and then catching the resulting error, but I have learned one or two (see also internal thread "Android and java7 Futures.getChecked()" about log spam) lessons about that, at least one of which is unlikely to be news to you :)).
• I have seen a handful of problems when experimenting with adding default methods in Guava inside Google. (See bug 229266760.) One of them is a result of a system that ill-advisedly tries to use a mix of the internal Guava and the external Guava (with the external Guava still lacking the default method), but I'm not sure I ever had a theory for the other. Anyway, adding the default methods would probably work fine, but I'd advise factoring in at least a little possibility that it turns out not to.
• Lambda and method references should be entirely fine :) Maybe also remove some unnecessary final keywords from effectively final variables if you have any of those hanging around.
• Kudos on actually using --release to avoid ByteBuffer issues (not that GSON appears to use the class) and other horrors.

[Marcono1234]

If you want you can also adjust the build setup to properly support JDK 21, since the only blocking thing was using Java 7 as target. So basically your changes from #2690, except:

• Omit the JAPICMP-OLD changes (that has already been solved)
• In build.yml also remove ${{ matrix.extra-mvn-args || '' }}
• In the README, adjust

  JDK 17 is recommended. Newer JDKs are currently not supported for building

This would then close #2501

Or alternatively I can also do that in a separate PR if you prefer.

---

It seems there are also a few comments in the code suggesting refactoring for Java 8:

• These Error Prone patterns can probably be enabled now, but might introduce a lot of new warnings; so maybe worth doing in a separate PR?
  

  gson/pom.xml

  Lines 283 to 286 in 3ce6eb8

  	-Xep:UnnecessaryAnonymousClass:OFF <!-- disabled: requires Java 8 -->
  	-Xep:UnnecessaryBoxedVariable:WARN
  	-Xep:UnnecessaryDefaultInEnumSwitch
  	-Xep:UnnecessaryFinal:OFF <!-- disabled: requires Java 8 -->

• Using Executable might simplify the code, but it seems Android only has it since API level 26 so we cannot use it yet.
  

  gson/gson/src/main/java/com/google/gson/internal/reflect/ReflectionHelper.java

  Lines 131 to 132 in 3ce6eb8

  	// Ideally parameter type would be java.lang.reflect.Executable, but that was added in Java 8
  	private static void appendExecutableParameters(

• gson/gson/src/main/java/com/google/gson/internal/NonNullElementWrapperList.java

  Line 130 in 3ce6eb8

  // TODO: Once Gson targets Java 8 also override List.sort

[eamonnmcmanus]

OK, I'm proposing to merge this change as is and address any comments in followups. @Marcono1234 if you want to send PRs for the items you mention, I would certainly appreciate that.