# Math With Java Integer Scalar Types

# Math With Java Integer Scalar Types

### Check out this romp through math using Java integer scalar types. We'll explore under and overflow in our look at

Join the DZone community and get the full member experience.

Join For FreeLearn how to build stream processing applications in Java-includes reference application. Brought to you in partnership with Hazelcast.

I'm pretty sure that most developers do not think about how to do right math with scalar types in Java. Experienced developers can say - "we do not use scalar types for business math, for this we use **java.lang.BigDecimal.**" And it is true, in Java world all business math operations used **java.lang.BigDecimal** or **java.lang.BigInteger** classes. But this article is not for business math.

Almost all Java developers know that the integer operators do not indicate overflow or underflow in any way (jls-4.2.2).

For instance, we have to calculate half of the sum of variables **a** and **b**. Let's say that variables have type **int** and (a%2 ==0, b%2 == 0). Below we have the method **doJob**.

```
public int doJob(int a, int b) {
...
}
```

For this job (calculating half of the sum **a** and **b**) almost all developers will write code like this:

```
public int doJob(int a, int b) {
return (a + b)/2;
}
```

Even though they know about jls-4.2.2, but someone can say - "In my situation there is no possible way for **a** and **b **when the result of the **doJob** method will overflow or underflow." But when it somehow happens, there will be overflow or underflow. How can I rewrite the result in the **doJob** method to avoiding this? The answer is we must take care of expression. For any type of expression, you need to think how to write it more optimized to minimizing or even avoiding overflow or underflow.

We can rewrite this method:

```
public int doJob(int a, int b) {
return a/2 + b/2;
}
```

The current implementation avoids all collision of jls-4.2.2.

But ok, if we have expressions like this:

- a + b
- a * b
- etc.

In Java 8 we have in class**java.lang.Math**additional methods for checking overflow and underflow:

```
public static int addExact(int x, int y)
public static long addExact(long x, long y)
public static int subtractExact(int x, int y)
public static long subtractExact(long x, long y)
public static int multiplyExact(int x, int y)
public static long multiplyExact(long x, long y)
public static int incrementExact(int a)
public static long incrementExact(long a)
public static int decrementExact(int a)
public static long decrementExact(long a)
// etc.
```

All these methods may throw **ArithmeticException**.

And now we do not need to check overflowing or underflowing by ourselves, we can use very helpful method like in this example:

```
public int doJobSum(int a, int b) {
return Math.addExact(a, b);
}
```

That's all, and if the result will overflow **int **type** **method **addExact **will throw **ArithmeticException**.

If you will check class **java.lang.Math **you can find many helpful methods since **Java 8**.

Learn how to build distributed stream processing applications in Java that elastically scale to meet demand- includes reference application. Brought to you in partnership with Hazelcast.

Opinions expressed by DZone contributors are their own.

## {{ parent.title || parent.header.title}}

## {{ parent.tldr }}

## {{ parent.linkDescription }}

{{ parent.urlSource.name }}