JSR-303 and JSR-305

376 views
Skip to first unread message

Bill Pugh

unread,
Jun 16, 2007, 1:22:06 PM6/16/07
to jsr...@googlegroups.com
OK, from the JavaOne talk on JSR-303, it seems clear that we should
be talking to JSR-303.

Very little public information is available on JSR-303, but it seems
to be based on Hibernate Validation.

Hibernate validate defines the following annotations:

@Length(min=, max=)
@Max(value=)
@Min(value=)
@NotNull
@NotEmpty
@Past@Future
@Pattern(regex="regexp", flag=)
@Patterns( {@Pattern(...)} )
@Range(min=, max=)
@Size(min=, max=)
@Email
@CreditCardNumber
@Digits
@EAN

The my personal proposal for JSR-305 predefined type qualifiers
includes (by the way, I've been updating http://code.google.com/p/
jsr-305/; I'll get some JavaDoc posted shortly).

@Nonnull @Nullable @CheckForNull

@Nonnegative @Signed @CheckForSigned

@Untainted @Tainted @Detainted

@Pattern(value="regexp",flag=)
@PropertyKey
@RegEx
@Syntax(value=)

So, it would be nice to agree on one name to indicate the idea that
something is not allowed to be null (NotNull, Nonnull, etc), but that
might be difficult to achieve agreement on.

What do you think about the rest of the annotations defined by
Hibernate Validation?

It would be nice that if you used Hibernate validation, static
analysis tools would interpret the results. But I'm not sure how many
of them we should make also be part of the standard JSR-305
distribution (e.g., I don't think we need to define @CreditCardNumber
as a standard JSR-305 annotation).


Bill

Brian Goetz

unread,
Jun 20, 2007, 11:56:33 AM6/20/07
to jsr...@googlegroups.com
> What do you think about the rest of the annotations defined by
> Hibernate Validation?

It reinforces my belief that annotations are not a powerful enough tool
to do what people want with them. (For example, annotations cannot have
a superinterface, so it is hard for tools to figure out what role an
annotation might play.)

It would be nice if we could talk them into doing something like

@Validation(@CreditCardNumber)

or something like that. (Sucking names like Length/Max/Min/Size out of
the namespace to do something as narrow as ORM-specific validation seems
inappropriate, but EE JSRs have done that all along -- think
@Stateless). But they won't do that, because every JSR EG committee
thinks their particular thing is the most important thing in the platform.

> It would be nice that if you used Hibernate validation, static
> analysis tools would interpret the results. But I'm not sure how many
> of them we should make also be part of the standard JSR-305
> distribution (e.g., I don't think we need to define @CreditCardNumber
> as a standard JSR-305 annotation).

No, we don't. Though we did talk about meta-annotations; there could be
a @ValidationAnnotation meta-annotation that at least tagged it as a
validated property.

Reply all
Reply to author
Forward
0 new messages