Grok Programming

One of the things I thought might be a good idea for keeping my feet to the fire on keeping up with what is going on in the Java world is to pull some of the currently open Java Specification Requests (JSRs) down and actually read the documentation they are producing. For the most part I’m going to digest the information in the documents and just write about the interesting bits. The crappy bits will be thrown over the fence to the C# folks (yeah, yeah like they need more crap). The goal of these “for Morons” posts is to give you the basics about a specific JSR - enough to hold a reasonable conversation about it so that you don’t sound like a moron - and to point you to where you can read or learn more if you feel like it. I’m sure I’ll toss in a dash of my own excellent opinions about the JSRs here and there too. Lucky you.

So, without any more delay let’s dive into JSR 303: Bean Validation.

On two occasions I have been asked,—”Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?” I am not able rightly to comprehend the kind of confusion of ideas that could provoke such a question. - Charles Babbage

What the hell is this?

JSR 303: Bean Validation is a specification in the early draft stage that is looking to add an API to Java that would allow developers a consistent way to validate JavaBeans. Anyone that has written any software for use by people other than themselves certainly understands the meaning of the old saying “garbage in, garbage out“. Validating the inputs to your JavaBeans is a useful way of ensuring that craptastic cycle doesn’t even start.

The Bean Validation spec is designed to be used anywhere JavaBeans are within an application. There is no limiting its use to Web Beans, domain objects, service classes, or any layers that the application may have. The intent of JSR 303 is as long as the target classes are actual JavaBeans then the validation framework should work just fine with it.

The Cliff Note Version

The basic pieces of JSR 303 are the @Constraint annotations and a validator for those constraints.  One of the more interesting aspects of the @Constraint annotations are the “message” and “group” properties you can attach to it.  The “message” property is used to create error messages when validation fails.  The “group” property is even cooler in that it allows you to control the order the validations are evaluated in or simply to do partial validation of a bean.  Example constraint annotations are @NotNull or @Max (length).

One of my favorite aspects of the spec is that constraints can be declared on super classes or interfaces and have them apply to classes the extended the super class or implement the interface.  This could be useful if you decided to create a base Entity interface and put contraints on the database identifier that each entity should have.

The validation process within the spec is well thought out and looks to relieve the developer of a lot of plumbing code.  For example, the validation code will walk object graphics if the correct annotations are present.  A developer wouldn’t have to chain call the validations directly.  This will be huge in that once the validation annotations are setup it’ll “just work” without the chance that another developer might forget to do part of the validation chain.

Like I said in the beginning this is just a short overview of what is in the spec covering those points I thought most developers would be interested in.

The Good

Much like declarative transaction and security are on the “solved problems” list in the Java world this spec moves validation onto that list.  I know there have been validation frameworks before this JSR but it is nice to have a standard way of doing validation.  Plus, it might just end the constant arguments on development teams on where validations happens. :)  I think taking a step to ensure object validations are declarative and outside of the developer’s direct concern will allow more consistancy in verifying the state of objects in Java applications.

The Bad

While not really a huge drawback the use of annotations pretty much locks out anyone not on Java 5 or later from using the JSR 303 implementation.  Again, not a huge deal since Java 5 is already at end of life support but there are people out there still on pre-Java 5 VMs (poor suckers).

The Ugly

The ugliest part I see with the currect spec is that it is JavaBean validation.  If I have validation needs that aren’t on JavaBeans then I’m screwed.  If I have taken Neal Ford’s “Question Authority” to heart and I don’t mindless follow the JavaBean spec and instead implement my domain using fluent interfaces then this validation won’t work for me.  I’m sure the JSR folks had to pick a direction to go in.  But with frameworks like Spring, Hibernate, and Seam able to work with fluent interfaces with much larger logical ground to cover you’d think the JSR could too.

Now, to be fair the spec does allow you to put the validations on fields and field access will be used during the validation process so I’m not totally clear why the emphasis on the fact that it is JavaBean validation framework.  Maybe that focus in the spec should be dropped or down played a bit.

Final Thoughts

I think this spec is fantastic for moving validations into the list of non-problems in Java.  In fact, I’d suspect that once people got used to them having to code validations into classes will feel “old school” and “quaint”.  I think developers wanting to see what’s coming down the pipe would do well to read over the spec.  It’s really small at only 39 pages or so and reads really well.

References

JSR-303: Bean Validation

JSR 303: Time to Standardize Validation

Hibernate Validator