See https://bugs.openjdk.org/browse/JDK-8309155

PiperOrigin-RevId: 608688611

TESTED: unknown commit
PiperOrigin-RevId: 608797794

#4291

PiperOrigin-RevId: 609002759

PiperOrigin-RevId: 609097523

PiperOrigin-RevId: 609364784

…gester

PiperOrigin-RevId: 609382750

…n useful values

By limiting our eagerness to annotate eligible Builder methods to only the `abstract` methods. We don't suggest annotating abstract/overridable methods with @cirv in general, but for Builders, we choose to do so, since we expect that the only reasonable override of the method involves returning "this" or similar.

PiperOrigin-RevId: 609396324

And consolidate some reflective workarounds for switch API changes.

Fixes #4266

PiperOrigin-RevId: 609484284

… automation).

Also, add a comment about manually providing an index if you need a stable one.

PiperOrigin-RevId: 609531242

PiperOrigin-RevId: 610431336

There's a subtle logic error here: empty fixes are meant to be emitted, there's just no fix.

PiperOrigin-RevId: 610434295

…tThrows(MyException.class, () -> ...);`

PiperOrigin-RevId: 610457244

PiperOrigin-RevId: 612829610

Rather than throwing an `NoSuchElementException`.

Fixes #3908.

Fixes #4028

COPYBARA_INTEGRATE_REVIEW=#4028 from PicnicSupermarket:gdejong/remove-disabled-checks 3a75f22
PiperOrigin-RevId: 612956455

## Summary

Minimal set of changes to ship a `module-info.java`, and support JVM 1.8 for the `annotations` module only.

### Reasoning

It costs almost nothing to support _only_ the annotations on JVM 1.8, for projects which transitively include `error-prone-annotations`, which can happen via a simple dependency on something like Guava. But, it would be ideal to [ship a `module-info.java`](#2649), so `annotations` is now a `Multi-Release` JAR, with a `module-info.class` in `META-INF/versions/9`.

I am working downstream to [support JPMS in Guava](google/guava#2970), and this PR will be necessary for that to eventually land (without hackery). [Checker Framework recently merged their support](typetools/checker-framework#6326) which means Error Prone is one of the last things on the classpath for Guava without a `module-info.java` definition.

Automatic Modules also aren't the answer because they cannot be used with `jlink`. Such dependencies must be processed by tools like Moditect before they can be used in fully modular Java builds. Because Error Prone Annotations is a dependency in Guava, and is itself very popular, many projects need Error Prone to adopt JPMS so they can ship their own code with modular Java support.

There may be libraries out there that depend on the annotations _and not the compiler_, who wish to ship a MRJAR and retain JVM 1.8 support (Guava).

### Non-release version number change

One wrinkle here is that the Maven project version [is used unconditionally](https://github.com/apache/maven-compiler-plugin/blob/74cfc72acae4f55708bca189b2170167e83df6b3/src/main/java/org/apache/maven/plugin/compiler/CompilerMojo.java#L304-L305) [as the `--module-version`][0]; however, [`HEAD-SNAPSHOT` is not a valid module identifier](https://lists.apache.org/thread/qtghq13qgjoc4pn6ovsdxgnjnm4ozv4d). This leaves only a few choices to support JPMS through recent (`3.8.x+`) Maven Compiler plugin versions:

- `HEAD-SNAPSHOT` needs to become `1.0-HEAD-SNAPSHOT`, and then it is a valid `--module-version`
- Or, Maven Compiler Plugin needs to ship a bugfix and Error Prone will need to wait for a release (if a bugfix ships at all)

I understand this can be a breaking change somewhere within Google, but I don't see a way around this without resorting to severe build hacks. I've gotten it to build anyway by building the `module-info.java` only in a separate Maven project, and then copying it into the JAR at the last moment, but there are serious issues with that route so I suggest it be abandoned in favor of a version string change during dev, if possible.

## Changelog

- feat: add `module-info` to `annotations` module
- feat: ship `annotations` as a `Multi-Release` JAR
- feat: support `1.8` through latest JDK for `annotations` module
- fix: remove automatic module definition from `annotations` module
- fix: `HEAD-SNAPSHOT` → `1.0-HEAD-SNAPSHOT`, because of a Maven Compiler Plugin issue [precluding use as a module version][0]

Fixes and closes #2649

[0]: https://issues.apache.org/jira/browse/MCOMPILER-579

Fixes #4311

COPYBARA_INTEGRATE_REVIEW=#4311 from sgammon:feat/jpms d209b0c
PiperOrigin-RevId: 614026439

#4314 (comment)

Fixes #4314

COPYBARA_INTEGRATE_REVIEW=#4314 from cushon:module 604430d
PiperOrigin-RevId: 614276837