**I just announced the new *** Learn Spring * course, focused on the fundamentals of Spring 5 and Spring Boot 2:

*Learn Spring*course, focused on the fundamentals of Spring 5 and Spring Boot 2:

**>> CHECK OUT THE COURSE**

Last modified: February 28, 2020

In this tutorial, we'll look at the overflow and underflow of numerical data types in Java.

We won't dive deeper into the more theoretical aspects — we'll just focus on when it happens in Java.

**First, we'll look at integer data types, then at floating-point data types. For both, we'll also see how we can detect when over- or underflow occurs.**

Simply put, overflow and underflow happen when we assign a value that is out of range of the declared data type of the variable.

**If the (absolute) value is too big, we call it overflow, if the value is too small, we call it underflow. **

Let's look at an example where we attempt to assign the value *10 ^{1000}* (a

As a second example, let's say we attempt to assign the value *10 ^{-1000}* (which is very close to 0) to a variable of type

Let's see what happens in Java in these cases in more detail.

The integer data types in Java are *byte* (8 bits), *short* (16 bits), *int* (32 bits), and *long* (64 bits).

**Here, we'll focus on the int data type. The same behavior applies to the other data types, except that the minimum and maximum values differ.**

An integer of type *int* in Java can be negative or positive, which means with its 32 bits, we can assign values between *-2 ^{31} *(

The wrapper class *Integer* defines two constants that hold these values: *Integer.MIN_VALUE* and *Integer.MAX_VALUE*.

What will happen if we define a variable *m* of type *int* and attempt to assign a value that's too big (e.g., *21474836478 = MAX_VALUE + 1)?*

A possible outcome of this assignment is that the value of *m* will be undefined or that there will be an error.

Both are valid outcomes; however, in Java, the value of *m* will be *-2147483648* (the minimum value). On the other hand, if we attempt to assign a value of -2147483649 (*= MIN_VALUE – 1*), *m* will be *2147483647 *(the maximum value). **This behavior is called integer-wraparound.**

Let's consider the following code snippet to illustrate this behavior better:

int value = Integer.MAX_VALUE-1; for(int i = 0; i < 4; i++, value++) { System.out.println(value); }

We'll get the following output, which demonstrates the overflow:

2147483646 2147483647 -2147483648 -2147483647

**Java does not throw an exception when an overflow occurs; that is why it can be hard to find errors resulting from an overflow.** Nor can we directly access the overflow flag, which is available in most CPUs.

However, there are various ways to handle a possible overflow. Let's look at several of these possibilities.

If we want to allow values larger than *2147483647* (or smaller than *-2147483648*), we can simply use the *long* data type or a *BigInteger* instead.

Though variables of type *long* can also overflow, the minimum and maximum values are much larger and are probably sufficient in most situations.

The value range of *BigInteger* is not restricted, except by the amount of memory available to the JVM.

Let's see how to rewrite our above example with *BigInteger*:

BigInteger largeValue = new BigInteger(Integer.MAX_VALUE + ""); for(int i = 0; i < 4; i++) { System.out.println(largeValue); largeValue = largeValue.add(BigInteger.ONE); }

We'll see the following output:

2147483647 2147483648 2147483649 2147483650

As we can see in the output, there's no overflow here. Our article *BigDecimal* and *BigInteger* in Java covers *BigInteger* in more detail.

There are situations where we don't want to allow larger values, nor do we want an overflow to occur, and we want to throw an exception instead.

**As of Java 8, we can use the methods for exact arithmetic operations.** Let's look at an example first:

int value = Integer.MAX_VALUE-1; for(int i = 0; i < 4; i++) { System.out.println(value); value = Math.addExact(value, 1); }

The static method *addExact()* performs a normal addition, but throws an exception if the operation results in an overflow or underflow:

2147483646 2147483647 Exception in thread "main" java.lang.ArithmeticException: integer overflow at java.lang.Math.addExact(Math.java:790) at baeldung.underoverflow.OverUnderflow.main(OverUnderflow.java:115)

In addition to *addExact()*, the *Math* package in Java 8 provides corresponding exact methods for all arithmetic operations. See the Java documentation for a list of all these methods.

Furthermore, there are exact conversion methods, which throw an exception if there is an overflow during the conversion to another data type.

For the conversion from a *long* to an *int*:

public static int toIntExact(long a)

And for the conversion from *BigInteger* to an *int* or *long*:

BigInteger largeValue = BigInteger.TEN; long longValue = largeValue.longValueExact(); int intValue = largeValue.intValueExact();

**The exact arithmetic methods were added to Java 8. If we use an earlier version, we can simply create these methods ourselves.** One option to do so is to implement the same method as in Java 8:

public static int addExact(int x, int y) { int r = x + y; if (((x ^ r) & (y ^ r)) < 0) { throw new ArithmeticException("int overflow"); } return r; }

The non-integer types *float* and *double* do not behave in the same way as the integer data types when it comes to arithmetic operations.

One difference is that arithmetic operations on floating-point numbers can result in a *NaN*. We have a dedicated article on NaN in Java, so we won't look further into that in this article. Furthermore, there are no exact arithmetic methods such as *addExact* or *multiplyExact* for non-integer types in the *Math* package.

Java follows the IEEE Standard for Floating-Point Arithmetic (IEEE 754) for its *float* and *double* data types. This standard is the basis for the way that Java handles over- and underflow of floating-point numbers.

**In the below sections, we'll focus on the over- and underflow of the double data type and what we can do to handle the situations in which they occur.**

As for the integer data types, we might expect that:

assertTrue(Double.MAX_VALUE + 1 == Double.MIN_VALUE);

However, that is not the case for floating-point variables. The following is true:

assertTrue(Double.MAX_VALUE + 1 == Double.MAX_VALUE);

**This is because a double value has only a limited number of significant bits. If we increase the value of a large double value by only one, we do not change any of the significant bits. Therefore, the value stays the same.**

If we increase the value of our variable such that we increase one of the significant bits of the variable, the variable will have the value *INFINITY*:

assertTrue(Double.MAX_VALUE * 2 == Double.POSITIVE_INFINITY);

and *NEGATIVE_INFINITY* for negative values:

assertTrue(Double.MAX_VALUE * -2 == Double.NEGATIVE_INFINITY);

**We can see that, unlike for integers, there's no wraparound, but two different possible outcomes of the overflow: the value stays the same, or we get one of the special values, POSITIVE_INFINITY or NEGATIVE_INFINITY.**

There are two constants defined for the minimum values of a *double* value: *MIN_VALUE* (4.9e-324) and *MIN_NORMAL *(2.2250738585072014E-308).

IEEE Standard for Floating-Point Arithmetic (IEEE 754) explains the details for the difference between those in more detail.

Let's focus on why we need a minimum value for floating-point numbers at all.

**A double value cannot be arbitrarily small as we only have a limited number of bits to represent the value.**

The chapter about Types, Values, and Variables in the Java SE language specification describes how floating-point types are represented. The minimum exponent for the binary representation of a *double* is given as *-1074*. That means the smallest positive value a double can have is *Math.pow(2, -1074)*, which is equal to *4.9e-324*.

As a consequence, the precision of a *double* in Java does not support values between 0 and *4.9e-324, *or between* -4.9e-324 *and* 0 *for negative values.

So what happens if we attempt to assign a too-small value to a variable of type *double*? Let's look at an example:

for(int i = 1073; i <= 1076; i++) { System.out.println("2^" + i + " = " + Math.pow(2, -i)); }

With output:

2^1073 = 1.0E-323 2^1074 = 4.9E-324 2^1075 = 0.0 2^1076 = 0.0

We see that if we assign a value that's too small, we get an underflow, and the resulting value is *0.0* (positive zero).

Similarly, for negative values, an underflow will result in a value of *-0.0* (negative zero).

**As overflow will result in either positive or negative infinity, and underflow in a positive or negative zero, we do not need exact arithmetic methods like for the integer data types.** Instead, we can check for these special constants to detect over- and underflow.

If we want to throw an exception in this situation, we can implement a helper method. Let's look at how that can look for the exponentiation:

public static double powExact(double base, double exponent) { if(base == 0.0) { return 0.0; } double result = Math.pow(base, exponent); if(result == Double.POSITIVE_INFINITY ) { throw new ArithmeticException("Double overflow resulting in POSITIVE_INFINITY"); } else if(result == Double.NEGATIVE_INFINITY) { throw new ArithmeticException("Double overflow resulting in NEGATIVE_INFINITY"); } else if(Double.compare(-0.0f, result) == 0) { throw new ArithmeticException("Double overflow resulting in negative zero"); } else if(Double.compare(+0.0f, result) == 0) { throw new ArithmeticException("Double overflow resulting in positive zero"); } return result; }

**In this method, we need to use the method Double.compare(). The normal comparison operators (< and >) do not distinguish between positive and negative zero.**

Finally, let's look at an example that shows why we need to be careful when working with positive and negative zero and infinity.

Let's define a couple of variables to demonstrate:

double a = +0f; double b = -0f;

**Because positive and negative 0 are considered equal:**

assertTrue(a == b);

**Whereas positive and negative infinity are considered different:**

assertTrue(1/a == Double.POSITIVE_INFINITY); assertTrue(1/b == Double.NEGATIVE_INFINITY);

However, the following assertion is correct:

assertTrue(1/a != 1/b);

Which seems to be a contradiction to our first assertion.

In this article, we saw what is over- and underflow, how it can occur in Java, and what is the difference between the integer and floating-point data types.

We also saw how we could detect over- and underflow during program execution.

As usual, the complete source code is available over on Github.