Hello, I'm so newbie in the Hiberante world, but i'm using it for some months ago, and really very happy with direction on JSR-303 that seem to standardize validation task.
I agree with 'bodrin' but not at all, my obserbation of the current problem, that in fact can be 3 scenarios for validator instance:
1) The validator not need initialization at all, and no receive parameters.
This can be the more common case that 'bodrin' point, and in fact most of the validation instances are working on this scenario:(AssertFalseValidator, AssertTrueValidator, EANValidator, FutureValidator, NotNullValidator, NotEmptyValidator, PastValidator)
2) The validator not need initialization at all, and receive parameters.
Here all that receive parameters and don't have any initialization process except copy required parameters for validation:
(DigitsValidator, LengthValidator, MaxValidator, MinValidator, RangeValidator , SizeValidator)
3) The validator need initialization with or without parameters.
With initialization, with or without parameters, the fact that not have parameters take a additional hint:
- In fact as i can see all annotations have a parameter 'message' that is not used at isValid() phase, so is hiberante validator create two different instances of validator impl? I need to check this I'm not sure.
(EmailValidator, PatternValidator)
1 - I also have a lot of validator implementations for our applications that fall back to this (is hiberntate treat the message parameter as different for two validators that have different messages?), so for this kind of implementation that in fact is thread safe, so only the Object value passed is used for validation.
2. - This case for fall to type 3 so validators that need parameters will run faster if it not need to access parameters via call (anotation.value()) that is proposed by 'borin' interface (boolean isValid(Object value, A constraintAnnotation)) i no check the generated byte code, but seems that access class property is more faster that method call, not sure at all, so I fall-back to type 3 so simplification of implementation, and no break current implementations.
3. - In this case we get some of our impls, also in case 2, but for me is the same case :), i think this case will implement void initialize(A constraintAnnotation); so in this case makes sense make a diferent instance for diferent parameters).
So for mu optimization point of view, there is a hint on implementation caching of validators to not duplicate instances when not needed, this can consider case 2 but if we revise case 3 seem that if a instance is created for different parameter will meet the specification, and no make duplicated instances, so my question is how different parameters for caching instances is treated?
I vote for this implementation and interfaces that will hit performance on initialization, use less memory at runtime for not initialized validators:
Code:
public interface Validator {
/**
* does the object/element pass the constraints
*/
public boolean isValid(Object value);
}
Code:
public interface InitializedValidator<A extends Annotation> {
/**
* Take the annotations values
*
* @param parameters
*/
public void initialize(A parameters);
}
This make the only implementation requirement are for all case 2 and case 3 are add the implements InitializedValidator<>, and for case 1 remove initialize decalrations.
Other change is in Caching validator instances, i not know the current implementation is done, so I revise source code and make some test cases, when I get some free time.
I apologize for simplify the API, i thick that two interfaces as saying 'bodrin' is best, so the validator implementation only depends on one simple method for simple validations that in fact is not using annotations at all, I think that this will fit for cases as pointed by 'borin' under memory constraints are hard, i'm fighting in the embedded world also :), so if this proposal of split interfaces are better focused on API implementation that on performance hit say me and split the issue in two:
1 - Performance issue in duplicate instances created fo the in fact same validator
2 - Simplify API implementation splitting the Validator interface in two more convenient interfaces Validator and InitializedValidator
Very impresive proyect, i'm really happy with standarized validation :).
Regards.
Login
FAQ
Search
