In Java 8, some of the primitive wrapper classes have gotten sum, max and min methods just so you can use them as method references. I don't really see the need for those max and min methods, but sum can definitely be useful.
In addition, Math got the following:
* addExact (int or long)
* multiplyExact (int or long), multiplyFull (int -> long) and multiplyHigh (long)
* floorDiv (int or long)
* subtractExact (int or long)
Rob Spoor wrote:...but sum can definitely be useful...
I got curious and checked 1.8 source. I found that the code for sum for Integer, Long, Double is exactly the same (i.e. return a+b;). I also found that min, max are just delegating calls to Math.min and Math.max.
It's good to know that these methods exist
As a student of "code smells," I think it's interesting how at first I didn't stop to think much about the API that Ron offered. I saw it and did a quick double take thinking, "hmmm..." for about half a second, then moved on. When I read Salvin's response about it being a nice way to ensure at least one parameter was passed, I thought, "Ok, I guess that's fine." But when I read Mike's response, I also thought, "You know, Mike's right about that being somewhat unintuitive."
It seems like it would be perfectly reasonable to expect that you could do this:
If I only had an array of numbers, why should I have to provide one of the numbers separately? In this usage case where you'd have to pass in the head and tail of the array instead, the API breaks the Principle of Least Astonishment (POLA).
How should I address this API smell? Should I overload? Should I throw an exception?
I think in the end, I'd just go with throwing an exception in the exceptional case:
Sorry if it it seems like I'm just rambling; my point here isn't really the solution I'd take but the journey taken towards that decision. The diversity of opinions shared and the recognition of a smell is arguably the only thing that would compel you to refactor and improve the API. If neither of those two things were present, then we'd just keep on truckin' with a potentially flawed API. As a coach who teaches developers to do TDD, I think that's very interesting.