Anything easily implemented using a regexp should probably be left to that purpose. Libraries can easily provide patterns, or their own additional annotations, and making them a part of the standard when there's no clear benefit seems questionable.
One thing I *do* think is so common that it should be included is a check verifying that the integer argument passes a Luhn algorithm test. It's not amenible to regexp-based implementation. A Luhn algorithm check when combined with a length test can verify a CCN as at least potentially valid, but the Luhn algorith is used for all sorts
of other things, including all sorts of business registration numbers in various countries. It's not tough to implement and requires little code, but it's something that a one-liner @Luhn annotation would be very handy for. See: http://en.wikipedia.org/wiki/Luhn_algorithm
. People are sure to ask for CCN validation, and this lets it be done with code that's also useful for all sorts of other things.
Another that would be useful would be an annotation to check a string against the Luhn algorithm after conversion to long by stripping all non-digit chars (by default) or an argument-specified list of "ignored" chars if one is given. Eg: @LuhnString(ignore="-_ ") .
(Any implementation should avoid string chopping
in its implementation. It's easily properly implemented using purely arithmetic operations, though most examples show the string-chopping method. I'll post a simple method shortly.)
By contrast, @Email in particular seems unwise, IMO. There are just too many different addressing rules, and they're sure to continue changing over time. Let people choose how strict they want to be and what set of rules they wish to obey by using an appropriate regexp with pattern validation.
I'd like to see an annotations library that suppliements the standard with a more flexible, but non-standardized, set of commonly used annotations such as various strictness levels of email validation, credit card number validation, ISBNs, Australian Company Number, Australian Business Number, etc etc. Something that can be built and included class file by class file in a modular manner, so apps aren't burdened with shipping huge chunks of unnecessary code as would be the case if all these were part of the JSR.
I've been pretty happy with what Hibernate Validator (as JSR303) provides as shipped. The only validator classes I've had to add are ones for ABNs and ACNs (as the app is mostly for Australian use) and some Luhn-algorithm based checks for some app-specific values where I use the Luhn algorithm to detect typos and miscommunication of ID numbers.