There is irregular code in the core libraries which computes the midpoint between two values. (They are often positive array indexes, but perhaps not always.)

There are at least three styles for coding such things:

```
  int mid = (lo + hi) / 2;
  int mid = (lo + hi) >> 1;
  int mid = (lo + hi) >>> 1;
  int mid = lo + (hi-lo) / 2;
  int mid = lo + ((hi-lo) >> 1);
  int mid = lo + ((hi-lo) >>> 1);
```

(H/T to Pavel R. for noticing this stuff in our code base.)

The last one is correct for all inputs, while the others (including the very tempting FORTRAN-style first one) have varying reactions to overflow conditions.

It's also anybody's guess which one the JIT prefers! Probably the `lo + (…)` forms are more JIT-friendly.

The right fix for this is to define an internal API point, akin to the index-checking API points we have in `jdk.internal.util.Preconditions `. (See JDK-8271164.) There should be both int and long versions. (Perhaps also float and double, for numeric mesh logic?)

It could go into `jdk.internal.util.Preconditions` or into a new class in that package.

```
/** Return a midpoint between the two values.
* If the difference is odd it the midpoint is rounded down.
* Numerically, it is {@code floor((lo+hi)/2)}.
* The result is undefined if {@code hi<lo}.
* (That is OK since this is a JDK internal method.)
*/
public static int midpoint(int lo, int hi) {
  return lo + ((hi - lo)>>>2);
}
…public static long midpoint(long lo, long hi)…
```

It might be a public service to export it as something like `Math.mid` or `Integer.midpoint`. To restrict undefined behavior, it would be reasonable to throw `IAE` if the inputs are badly ordered. It is not a good idea to auto-sort them, because if the `hi` argument is an overflow value, it will appear to be a very negative one, and auto-sorting would just hide the bug.