Review Request: 8004201: add reducers to primitive type wrappers (original) (raw)

Akhil Arora akhil.arora at oracle.com
Mon Dec 10 23:45:27 UTC 2012

http://cr.openjdk.java.net/~akhil/8004201.2/webrev/

Thanks

On 12/05/2012 03:44 PM, Joseph Darcy wrote:

Akhil,

In javadoc like this 298 * as {@code BinaryOperator}. you don't have to use "<" and the like inside {@code}; please change to_ _298 * as {@code BinaryOperator}. As a general comment, if the operations for primitive type Foo are put into java.lang.Foo, then the type of the operation needs to be explicitly represented in the expression calling the method (unless static imports are used, etc.). Therefore, I suggest putting these sort of static methods all into one class to allow overloading to do its thing (java.lang.Operators?). Also, for methods like sum, I think it is worth considering returning a larger type than the operands to avoid problems from integer or floating-point overflow. For example, sum on byte and short would return int, sun on int would return long, etc. As an aside, to get a numerically robust result, the summation logic over a set of doubles needs to be more than just a set of raw double additions, but that can be tackled later. Cheers, -Joe

On 12/5/2012 1:27 PM, Akhil Arora wrote: Updated - http://cr.openjdk.java.net/~akhil/8004201.1/webrev/

- delegate to Math.min/max for int/long/float/double - rename Boolean.and/or/xor to logicalAnd/logicalOr/logicalXor - removed Character variants of min/max/sum On 12/02/2012 05:50 PM, David Holmes wrote: Hi Akhil,

Is it really necessary/desirable to flag all of these as " Suitable for conversion as a method reference to functional interfaces such as ..." ? Not necessary, but it does provide a hint as to their intended use to a casual browser of these docs. This style: + * @param a a boolean argument. + * @param b another boolean argument. is at odds with the style used elsewhere for new Functional APIs, and with the style of other methods in these classes. Can we just use "first operand" and "second operand" for all of these? It is consistent with Math.min/max, which use the a/b style. Since these methods are not in one of the functional package, is'nt it better to stick to the local style? Character.sum does not make sense to me. Who adds together characters? I'm not even sure min and max are worth supporting for Character. Good point - removed these methods for Character. I disagree with other suggestions to use the Math functions for float/double. I think all these methods should use the underlying primitive operator regardless of type. Are you disagreeing only for float/double or for int/long also? Can you provide more information as to why you disagree? Thanks Thanks, David ----- On 1/12/2012 4:44 AM, Akhil Arora wrote: Hi

Requesting review for some basic functionality related to lambdas - Add min, max, sum methods to the primitive wrapper classes - Byte, Short, Integer, Long, Float, Double and Character so as to be able to use them as reducers in lambda expressions. Add and, or, xor methods to Boolean. http://cr.openjdk.java.net/~akhil/8004201.0/webrev/ http://bugs.sun.com/bugdatabase/viewbug.do?bugid=8004201 Thanks

More information about the core-libs-dev mailing list