Page History

...

Because the ranges of Java types are not symmetric (the negation of each minimum value is one more than each maximum value), even operations like unary negation can overflow if applied to a minimum value. Because the java.lang.math.abs() method returns the absolute value on of any number, it can also overflow if given the minimum int or long as an argument.

...

The upcast technique is the preferred approach when applicable. The checks it requires are simpler than those of the previous technique; it is substantially more efficient than using BigInteger. Unfortunately, it cannot be applied to operations involving the biggest type long, as there is no bigger type to upcast to.

The BigInteger technique is conceptually the simplest of the three techniques because arithmetic operations on BigInteger cannot overflow. However, it requires the use of method calls for each operation in place of primitive arithmetic operators; this , which can obscure the intended meaning of the code. Operations on objects of type BigInteger can also be significantly less efficient than operations on the original primitive integer type.

...

Either operation in this noncompliant code example could produce a result that overflows the range of intresult in an overflow. When overflow occurs, the result will be incorrect.

...

This compliant solution shows the implementation of a method for checking whether a value of type long value falls within the representable range of an int using the upcasting technique. The implementations of range checks for the smaller primitive integer types are similar.

...

Note that this approach cannot be applied to values of type long because long is the largest primitive integral type. Use the BigInteger technique instead when the original variables are of type long.

...

Operations on objects of type AtomicInteger suffer from the same overflow issues as other integer types. The solutions are generally similar to the solutions already presented; however, concurrency issues add additional complications. First, potential issues with time-of-check, time-of-use (TOCTOU) must be avoided; see rule VNA02-J for more information. Second, use of an AtomicInteger creates happens-before relationships between the various threads that access it. Consequently, changes to the number of accesses or order of accesses can alter the execution of the overall program. In such cases, you must either choose to accept the altered execution or carefully craft the your implementation of your compliant technique to preserve the exact number of accesses and order of accesses to the AtomicInteger.

...

class InventoryManager {
  private final AtomicInteger itemsInInventory = new AtomicInteger(100);

  //...
  public final void nextItem() {
    itemsInInventory++.getAndIncrement();
  }
}

Consequently, itemsInInventory can wrap around to Integer.MIN_VALUE when the nextItem() method is invoked at the instant when itemsInInventory == Integer.MAX_VALUE.

...

...

...