Bean Validation API looks good, even after reading the spec
Here's another update: I wrote a bit about Bean Validation API (jsr-303) earlier, suggesting it might be something to look for.
And lo + behold, after finally taking time to read the underlying JSR specification (still a draft, not finalized, but rather complete it seems), I still like it! In fact, I think it's amongst the best JSRs I have read (granted, I have read but maybe dozen all in all -- quality of other hundred or so completed ones I can only speculate freely about).
So why is it good? Here are some reasons:
- Its scope is well-defined: the thing covers validation of beans, and only limited number of additions (like localization of error messages -- not needed for all use cases, but is for the "obvious" case of validating user input)
- "New" language features (like generics, annotations, enums) are used professionally: used when useful and/or necessary, but not going wild for sake of using them
- Innovative design within above bounds
- Specification itself is well-written as a technical document: concise, formal (enough) but readable (enough non-toy-examples, but not too many)
I am especially intrigued by #3: I think the way that validator factories are constructed is sensible, clever, and a clear improvement over way that many earlier JSRs defined creation of factories (like JAXP et al). The innovation parts is that instead of first locating a factory implementation and returning it for application to configure, order is actually reversed: process starts by constructing configuration object, and after it has been built (using fluent/fluid/builder style), only then the factory is created. The beauty of this is that the resulting factory is immutable and hence thread-safe (and specified to be so by the specs). Why is this such a big deal? Because it is now possible to safely instantiate just one (or at most couple) of such factories, to be shared by the whole application or subsystem. Although this can be done de factor for most factories (JAXB, DOM, Stax etc etc), this is not guaranteed by respective specification.
But benefits of this style extend beyond thread-safety part: it also allows for clean way of adding custom configurations (with help of using generics to define configurator objects), with bit more type safety. If you do know the provider to use (or at least extension(s) it defines), you can configure things, but still within same framework.
If above description seems fuzzy, go ahead and read the specification. It should make more sense, especially if you have had to create such pluggable-provider-factory frameworks.
So anyway, hats off to writers of JSR-303. I hope other aspiring (or veteran) JSR members will learn from it.
