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] |
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. |
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] |
Free forum by Nabble | Edit this page |