Anyone that has used the builder pattern for building simple Pojo-style Java classes is probably aware that writing these builder classes quickly becomes quite unpleasant and definitely not fun. You quickly realize that your builders often mimic the structure of your Pojo’s setters, finding yourself almost duplicating half of Pojo’s code for the sake of the pattern. Following a recent post from Eric Mignot and a few prior reflections I had on optimizing the process of writing these builders, I have come up with a solution that will, I hope, greatly simplify trivial cases (that is, building simple pojos) and, eventually, as the tool evolves, allow for slightly more complex cases to be covered. Read more...

If you’ve worked with Maven before, you are probably aware that it allows you to define custom properties that can then be used throughout your build as placeholders (for value re-use or configuration purposes) or even as a mean of configuring your final build resources using filters. These come very handy for defining environment-specific configurations. These custom properties can be defined at multiple locations. But what happens when you define (or re-define) the same property in multiple locations? Read more...

JSR-303 (Bean Validation) is nice. It allows to define validation rules directly on beans using simple annotations. Most cases are covered by the base annotations provided by the standard, and it even includes a way to develop custom validators that can be plugged-in as you see fit. Once your beans are annotated, you can manually trigger validation as simply as: Set<ConstraintViolation> constraintViolations = validator.validate(annotatedBeanInstance); The latest and greatest Spring 3 now supports JSR-303 validation out of the box. Read more...