[numbers] Redundant methods in ArithmeticUtils

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[numbers] Redundant methods in ArithmeticUtils

Heinrich Bohne
The class ArithmeticUtils in the commons-numbers-core module contains
several methods where, since Java 8, equivalent methods in
java.lang.Math exist. These methods are the following:

addAndCheck(int, int)
addAndCheck(long, long)
mulAndCheck(int, int)
mulAndCheck(long, long)
subAndCheck(int, int)
subAndCheck(long, long)

The corresponding methods from java.lang.Math are:

addExact(int, int)
addExact(long, long)
multiplyExact(int, int)
multiplyExact(long, long)
subtractExact(int, int)
subtractExact(long, long)

The former methods are probably relics from pre-Java-8 times, when the
latter methods did not exist. But now, they are redundant. I suggest
they be removed from ArithmeticUtils in commons-numbers-core, and their
invocations replaced by invocations of the java.lang.Math equivalents.
Both groups of methods specify the same type of exception to be thrown
in case of an overflow (a java.lang.ArithmeticException), so the
replacement should be straightforward.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Redundant methods in ArithmeticUtils

Eric Barnhill
On Tue, Jun 11, 2019 at 9:52 AM Heinrich Bohne <[hidden email]>
wrote:

> The class ArithmeticUtils in the commons-numbers-core module contains
> several methods where, since Java 8, equivalent methods in
> java.lang.Math exist. These methods are the following:
>
> addAndCheck(int, int)
> addAndCheck(long, long)
> mulAndCheck(int, int)
> mulAndCheck(long, long)
> subAndCheck(int, int)
> subAndCheck(long, long)
>
> The corresponding methods from java.lang.Math are:
>
> addExact(int, int)
> addExact(long, long)
> multiplyExact(int, int)
> multiplyExact(long, long)
> subtractExact(int, int)
> subtractExact(long, long)
>
> The former methods are probably relics from pre-Java-8 times, when the
> latter methods did not exist.


Often true with commons, and no shame in that.


> But now, they are redundant. I suggest
> they be removed from ArithmeticUtils in commons-numbers-core, and their
> invocations replaced by invocations of the java.lang.Math equivalents.
>

+1


> Both groups of methods specify the same type of exception to be thrown
> in case of an overflow (a java.lang.ArithmeticException), so the
> replacement should be straightforward.
>

Utils classes are of course frowned upon in general, so IMO the less in
there the better.
Reply | Threaded
Open this post in threaded view
|

Re: [numbers] Redundant methods in ArithmeticUtils

Gilles Sadowski-2
Hello.

Le mar. 11 juin 2019 à 19:26, Eric Barnhill <[hidden email]> a écrit :

>
> On Tue, Jun 11, 2019 at 9:52 AM Heinrich Bohne <[hidden email]>
> wrote:
>
> > The class ArithmeticUtils in the commons-numbers-core module contains
> > several methods where, since Java 8, equivalent methods in
> > java.lang.Math exist. These methods are the following:
> >
> > addAndCheck(int, int)
> > addAndCheck(long, long)
> > mulAndCheck(int, int)
> > mulAndCheck(long, long)
> > subAndCheck(int, int)
> > subAndCheck(long, long)
> >
> > The corresponding methods from java.lang.Math are:
> >
> > addExact(int, int)
> > addExact(long, long)
> > multiplyExact(int, int)
> > multiplyExact(long, long)
> > subtractExact(int, int)
> > subtractExact(long, long)
> >
> > The former methods are probably relics from pre-Java-8 times, when the
> > latter methods did not exist.
>
>
> Often true with commons, and no shame in that.

IMHO, when methods become obsolete, we should indeed remove them.
If an application upgrades, it must switch to the JDK version of the
functionality (all benefit given the level of support we can provide).

> > But now, they are redundant. I suggest
> > they be removed from ArithmeticUtils in commons-numbers-core, and their
> > invocations replaced by invocations of the java.lang.Math equivalents.
> >
>
> +1

+1

> > Both groups of methods specify the same type of exception to be thrown
> > in case of an overflow (a java.lang.ArithmeticException), so the
> > replacement should be straightforward.
> >

PR welcome.

> Utils classes are of course frowned upon in general, so IMO the less in
> there the better.

I agree; but what would be the alternative for such "core" methods?
[The JDK also put them in a utility class.]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]