* Some public APIs have incorrect nullability annotations (both overly restrictive and overly permissive)

While there are competing ways to represent absence (`Optional`, "Null Object" pattern, method overloads),
it is unlikely that we'll be able to remove `null` entirely.

After migrating to Java 8, we can use pluggable type checkers to ensure that our annotations are consistent, 
and there are no missing null checks.

## Decision

	ok = true
	ctxt.DiagFunc = func(format string, args ...any) {
		t.Errorf(format, args...)
		ok = false
	}
	obj.Flushplist(ctxt, pList, nil)

	if !ok {
		// If we've encountered errors, the output is unlikely to be sane.
		t.FailNow()
	}

	for p := top; p != nil; p = p.Link {
		if p.As == obj.ATEXT {
			text = p.From.Sym
		}
		hexes := hexByLine[p.Line()]
		if hexes == "" {
			continue
		}

- For Dynamic Resource Allocation, labels in node selectors now are validated. Invalid labels already caused runtime errors before and are unlikely to occur in practice. ([#128932](https://github.com/kubernetes/kubernetes/pull/128932), [@pohly](https://github.com/pohly))

   * value slightly too high than slightly too low. If the value is not exact, the {@link
   * ImmutableLongArray} that is built will very likely occupy more memory than strictly necessary;
   * to trim memory usage, build using {@code builder.build().trimmed()}.
   */
  public static Builder builder(int initialCapacity) {

   * of values that will be added, if that knowledge is readily available. It is better to guess a
   * value slightly too high than slightly too low. If the value is not exact, the {@link
   * ImmutableIntArray} that is built will very likely occupy more memory than strictly necessary;
   * to trim memory usage, build using {@code builder.build().trimmed()}.
   */
  public static Builder builder(int initialCapacity) {

 * A {@code PathType} can identify the class path, the module path, the patches for a specific module,
 * or another kind of path.
 *
 * <p>One path type is handled in a special way: unlike other options,
 * the paths specified in a {@code --patch-module} Java option is effective only for a specified module.
 * This type is created by calls to {@link #patchModule(String)} and a new instance must be created for

   *       to make such changes to our serialized forms, and we have made them before, usually
   *       without trouble. In this case, my guess is that our chosen approach is even less likely
   *       to lead to trouble than an incompatible change would be.
   *   <li>We could make {@link #countMap} no longer be {@code final}. Then we could write to it

  }

  @AndroidIncompatible // b/391667564: crashes from stack overflows
  public void testSetIndirectSelf_toString() {
    SettableFuture<Object> orig = SettableFuture.create();
    // unlike the above this indirection defeats the trivial cycle detection and causes a SOE
    orig.setFuture(
        new ForwardingListenableFuture<Object>() {
          @Override

  }

  @AndroidIncompatible // b/391667564: crashes from stack overflows
  public void testSetIndirectSelf_toString() {
    SettableFuture<Object> orig = SettableFuture.create();
    // unlike the above this indirection defeats the trivial cycle detection and causes a SOE
    orig.setFuture(
        new ForwardingListenableFuture<Object>() {
          @Override

The new APIs use `mockwebserver3` in both the Maven coordinate and package name. This new API is
**not stable** and will likely change before the final 5.0.0 release.

If you have code that subclasses `okhttp3.mockwebserver.QueueDispatcher`, this update is not source
or binary compatible. Migrating to the new `mockwebserver3` package will fix this problem.