Survey - Behavior of @Positive and @Negative constraints
Based on our previous survey we’ve recently added the new constraints @Positive and @Negative to the Bean Validation spec.
Now we’ve had an interesting discussion on some details of those constraints,
e.g. should 0 (zero) be considered as a valid value by default?
I.e. what’s the more common use case, to consider 0 as valid or not?
So we thought let’s make another survey to gauge the community feedback on those issues. You’d help us very much by answering the two questions below, you won’t need more than a minute.
If you have any other thoughts you’d like to share, either add an answer to the free-text question or post a comment below. The survey will be open until the end of next week.
Thanks a lot for your help!
Survey - Where do you use constraints on parameterized type?
For Bean Validation 2, we are working on the support for Collection<@Email String>, Optional<@Min(3) Integer> etc.
This has been a very common request and with Java 8 type use support, we can how achieve this.
However, we need your feedback on how you would use such feature.
Some context
We have support not only for collections, Optional, Java FX properties but also for what we call custom parameterized containers.
We are wondering a few things about custom parameterized containers, namely how common they are.
This will affect the trade-offs we want to make on the design of that feature.
What is a container?
A container is a type that wraps and exposes one or several values.
The values is what you want to apply your constraints on.
And the container is parameterized because at use site, you can declare what type it actually contains.
For a Set<@Email String>, we want to make sure every string in the set is an email.
Another less obvious example is a tuple class.
public class Pair<V1,V2> {
V1 getV1() { ... }
V2 getV2(); { ... }
}
public class Address {
// street1 is mandatory, street2 is optional
// represented via a Pair object
Pair<@NotNull @Size(max=250) String, @Size(max=250) String> streetFields;
}Other examples are:
-
a tree structure containing specific object types
-
Guava’s Multimap (or any multimap for that matter)
Questions
We are wondering which type of parameterized containers you have in your code base and how likely you are going to apply constrains on their contained value. The form is a list of short questions that will help us get a better picture.
Here is the link to the form in a separate page or use it directly embedded below.
Many thanks!
Feedback needed - Which constraints should be added?
The work on Bean Validation 2.0 is in full swing and there is an issue where we could benefit from your help.
Recently we have been discussing whether any new constraints should be added to the specification or not.
Traditionally, Bean Validation stayed on the conservative side of things in this regard.
It defined only some generically applicable and widely useful constraints in the specification itself, e.g. @NotNull, @Size or @Pattern.
Now Marco Molteni did a very interesting analysis on the constraints which are actually used in real world projects by running an analysis of open source projects hosted on GitHub. Only a specific type of project is hosted there usually (mostly libraries, as opposed to actual end user facing applications), so the numbers should be taken with a grain of salt. But nevertheless they are very interesting.
Marco's analysis shows that besides the BV-defined constraints @NotEmpty and @NotBlank - both defined by the reference implementation Hibernate validator - are very frequently used and thus are potential candidates for inclusion into Bean Validation 2.0.
The former asserts that the annotated string, collection, map or array is neither null nor empty, the latter validates that the annotated string is neither null nor empty, stripping leading/trailing whitespace.
Another candidate may be @Email; but validation of e-mail addresses is a surprisingly complex business, with different people having different ideas and expectations of how a valid (or invalid) e-mail address should look like (take a look at the examples on Wikipedia to get an idea).
Hence I feel this is not something we should aim for in the specification.
To add some further data points, we created the following survey on constraints to be added potentially. Getting back many answers to this poll will help us to form a better understanding of what you, the users out there, really need. If you would like to see support for other constraints not mentioned in the survey, you can add them via the free-text field in the last question. These may be custom constraints defined by a Bean Validation provider, a third-party library or in your own projects which you see yourself using very frequently.
Taking the survey will take you only a minute, so give it a go. Thanks a lot for your help!
XML namespace and JCP
Antonio Goncalves, fellow JCP member and friend has asked me why Bean Validation XML's namespace has not moved from its original location to the jcp.org location like other Java EE 7 specifications.
I don't remember being aware that such a move was orchestrated so there are two possible reasons:
- I was never been made aware of the move,
- I was aware of it but considered that it was low priority compared to the other issues we were working on.
Provided we had to work hard till the last minute, and that the community never was keen on the XML support we put in Bean Validation, #2 is not impossible but I suspect it's #1 or I would have opened an issue to track the task.
Anyways, that's not a problem. Anyone can open an issue (I've just created one for this task), write a couple of pull requests to fix the spec, TCK and RI as explained in our contribute section. Scratch your own itch: so who's jumping? :)
We will have to wait for the next version of the spec to avoid breaking older applications but if it's committed, it won't be forgotten.
PS: no, I'm not bitter, but since I haven't blogged in a while that was a good occasion to remind everyone of the power of contributions ;)
Should getters be validated when they are called?
The expert group is agonizing on a specific issue. We need your feedback. Should getters be considered regular methods and thus be validated when called?
The problem
Existing applications put Bean Validation constraints on properties (ie getters). If we enable validations when getters are called, some applications might fail and Bean Validation would not be backward compatible. Besides, it is unlikely that you want to validate genuine getters when they are called. These are state, not operations for the most part.
First off what does it mean to be a getter. A method is a getter if:
- its name starts with
is, has no parameter and its return type isBoolean - or its name starts with
getand has not parameter
If in your service (say a CDI bean), you have an action method with
no parameter and starting with get, and if you have added constraints
to validate the return value upon method call, we cannot differentiate
this action method from a genuine getter.
We have several solutions to work around the problem and we would like to know which one you prefer.
Solutions
We can use a few levers to work around the issue:
- ask you to enable method validation explicitly
- offer a coarse or fine grained solution to change the default behavior
Solution 1: enable method validation out of the box
If method validation is enabled out of the box then the sensible default is to exclude getters from method validation.
This approach is friendly out of the box and will work as expected most of
the time (except for action methods with no parameter, starting with get
and with constraints on the return value).
The downside of this approach is that in this very specific case where an action method is also a getter, method validation would be disabled out of the box and a manual intervention would be necessary.
You can change the default approach in two ways:
Solution 1.a: global flag
Use a global flag to disable method validation entirely or ask for getters
to be validated upon call. You would use validation.xml for that:
<method-validation mode="INCLUDE_GETTERS"/>
There is no way to change the behavior for a specific (set of) class.
Solution 1.b: fine grained flag
An alternative solution is to change method validation behavior in a much more fine-grained approach:
- set the default approach globally
in
validation.xml - set or override the setting for a given package (including sub-packages?)
via
@ValidateOnCallas a package annotation (orvalidation.xml) - set or override the setting for a given class
via
@ValidateOnCallas a type annotation (orvalidation.xml) - set or override the setting for a given method
via
@ValidateOnCallas a method annotation (orvalidation.xml)
A @ValidateOnCall annotation can be overridden in validation.xml like we do for
constraints declarations.
public class AwesomeService {
// not a getter - validated by default
@NotNull Currency provideMainCurrency(@ISO @NotNull String country) { ... }
// not a getter - validated by default
@NotNull Currency getAlternativeCurrencies(@ISO @NotNull String country) { ... }
// getter - must use @ValidateOnCall to activate
@ValidateOnCall(mode=INCLUDE_GETTERS)
@NotNull getAllCurrencies() { ... }
}
Note that, we could put @ValidateOnCall(mode=INCLUDE_GETTERS) on the package
of service classes
@ValidateOnCall(mode=INCLUDE_GETTERS)
package com.acme.gladiator.action;
In this case, getAllCurrencies() does not need to be annotated with @ValidateOnCall.
Solution 2: disable method validation out of the box
In this situation, a user wanting to enable method validation needs to both:
- add the constraints on methods
- add the flag to enable method validation
The method validation flag would both allow it to be enabled and decide if getters should be considered.
This approach is the least surprise approach as nothing is happening that you have not explicitly asked for. The drawback is that it requires a manual intervention to enable method validation in a given archive which is not groovy.
Solution 2.a: global flag
For all archives using method validation, a META-INF/validation.xml file must
be added. The file would contain the explicit setting:
<method-validation mode="INCLUDE_GETTER"/>
There is no way to change the behavior for a specific (set of) classes.
Solution 2.b: fine grained flag
As described in the previous section, we could enable method validation at
the package, class and method level using either a @ValidateOnCall annotation
or via the validation.xml. In this approach, validation.xml is not mandatory
to enable method validation provided that you use @ValidateOnCall in your code.
So what's your favorite?
My personal favorite is to enable non-getter method validation out of the box and offer fine-grained options to override the behavior. That's solution 1.b. My reasoning is the following:
- I want ease of use and method validation enabled by default
- actions methods named like a getter, with no parameter and constraints on its return value will be rare - return value constraint are less common than parameter methods
Some in the expert group do prefer solution 2.a or 2.b.
What's your take? And why do you prefer this approach?
Latest news
Stay up to date, subscribe to the news feed.