On Feb 27, 2009, at 15:11, Hardy Ferentschik wrote: Looks like double is a no-go http://firstclassthoughts.co.uk/java/traps/java_double_traps.html

On Wed, Mar 4, 2009 at 3:49 PM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: How would you go about supporting @Max / @Min for java.math.BigDecimal ? These would be more useful, since think a lot of this sort of validation is intended to fulfill business rules and business math requires exact (not floating point) math. And even in situations you use floating point math, the input and state should be probably a BigDecimal value but internally calculations could be done (for sake of expedience) using a double conversion. I would probably create a separate @MaxDouble and @MinDouble annotation, if at all, but I wouldn't feel easy suggesting users build constraints using floating point comparisons.

I mean we could but we would need to rely on the string representation @interface Max { String value() } @Max("12.5") double someNumber; On Mar 4, 2009, at 19:17, Emmanuel Bernard wrote:

On Wed, Mar 4, 2009 at 4:20 PM, Emmanuel Bernard <emmanuel(a)hibernate.org&gt; wrote: There's very few domains where you want to be validating user input and storing it as a double. For reasons you talked about and also just for returning back what the user typed in a form, for instance, doubles aren't user friendly. Thus, I don't see why validating a double should be necessarily supported. Most developers people don't understand floating point very well, and your average user is unlikely to know about rounding errors and inexact representation, etc. In my original question, I was considering validation cases when you are using a BigDecimal. The common use case is validating a column from a database. Databases columns most often use exact representations of decimal numbers, for obvious reasons when working with money. There, you don't want to be storing data in doubles! In any case, I would assume you'd want to indicate something similar to: @Max("12.5") BigDecimal someNumber; Since the BigDecimal and BigInteger have String constructors that are well defined, a String representation seems fine. There's other restrictions you may want to make as well. For instance, you may want to restrict values to at most N decimal places or significant digits, i.e. precision. This is useful in scientific applications. How might you represent that?

I have gathered feedback from various places and as expected everyone has his favorite best solution. I am on the fence to support this: - @Max with long not supporting double and float - @MaxDecimal with String (BigDecimal style) not supporting double and float - same for min WDTY? Better names encouraged. /** * The annotated element must be a number whose value must be lower or * equal than the specificed maximum. * <p/> * Supported types are: * <ul> * <li><code>BigDecimal</code></li> * <li><code>BigInteger</code></li> * <li><code>byte</code>, <code>short</code>, <code>int</code>, <code>long</code> * and their respective wrappers</li> * </ul> * Note that double and float are not supported due to rounding errors (some providers * might provide approximative support) * <p/> * <code>null</code> elements are considered valid * * @author Emmanuel Bernard */ @Target({ METHOD, FIELD, ANNOTATION_TYPE }) @Retention(RUNTIME) @Documented public @interface Max { String message() default "{validator.max}"; Class<?>[] groups() default { }; /** * @return Value the element must be lower or equal to */ long value(); /** * Defines several @Max annotations on the same element * @see Max * * @author Emmanuel Bernard */ @Target({ METHOD, FIELD, ANNOTATION_TYPE }) @Retention(RUNTIME) @Documented @interface List { Max[] value(); } } /** * The annotated element must be a number whose value must be lower or * equal than the specificed maximum. * <p/> * Supported types are: * <ul> * <li><code>BigDecimal</code></li> * <li><code>BigInteger</code></li> * <li><code>byte</code>, <code>short</code>, <code>int</code>, <code>long</code> * and their respective wrappers</li> * </ul> * Note that double and float are not supported due to rounding errors (some providers * might provide approximative support) * <p/> * <code>null</code> elements are considered valid * * @author Emmanuel Bernard */ @Target({ METHOD, FIELD, ANNOTATION_TYPE }) @Retention(RUNTIME) @Documented public @interface MaxDecimal { String message() default "{validator.max}"; Class<?>[] groups() default { }; /** * The string representation of the max value according to the BigDecimal representation * @return Value the element must be lower or equal to */ String value(); /** * Defines several @Max annotations on the same element * @see Max * * @author Emmanuel Bernard */ @Target({ METHOD, FIELD, ANNOTATION_TYPE }) @Retention(RUNTIME) @Documented @interface List { Max[] value(); } }