No need to code - just annotate it...
TheServerSide reports that JSR 303 will solve the problem of validating beans in several tiers in the typical J2EE stack. A developer is supposed to annotate his bean with validation rules rather than code it in controller classes all over the system. This is probably a very nice effort to sort out one of the problems with the whole J2EE thing. It starts me wondering though. It seems like Java is moving from actual code towards more and more of the annotation stuff. (Which I don't like at all from the artistic perspective....) Annotations make sense for many things - mostly for matters concerning infrastructural issues. It also makes sense to annotate in order to validate proper values in a Java bean. And it highlights a problem that has been there all the time since Java beans appeared. The Java beans standard isn't really object oriented. It kind of assumes that a get/set pair encapsulates one field. The requirement of having an empty constructor also emphasizes that you can never trust a Java bean instance. The values can be whatever. And that is the reason you need a validation annotation framework. I think it is sad that a nice object oriented language like Java is used mostly for functional programming. Also sad is the complexity that is added when making workarounds for solving these issues.
I am not so sure, however, if the JavaBean standard is to blame. I agree that having an empty constructor allows for the creation of objects which might not encode a valid state, but what is the alternative? JavaBeans object are data holders in my opinion, meaning they don't contain much (if any) logic. They are mainly there to carry data and have a generic method to extract the data particularly also via introspection.