<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: Times New Roman; font-size: 12pt; color: #000000'>Hi,<br><br>Today many <a href="http://en.wikipedia.org/wiki/Plain_Old_Java_Object">POJO</a>s are used throughout the system to convey data:<br><ul><li> Parameters - To send data to commands.</li><li> Business Entities - To transfer data in the parameters & to/from the DB.</li></ul>These POJOs are (usually) very verbose and full of <a href="http://en.wikipedia.org/wiki/Boilerplate_code">boilerplate code</a>.<br><br>This, in turn, reduces their readability and maintainability for a couple of reasons (that I can think of):<br><ul><li>It's hard to know what does what:</li><ul><li>Who participates in equals/hashCode?</li><li>What fields are printed in toString? <br></li></ul><li>Consistency is problematic:</li><ul><li>A field may be part of equals but not hashCode, or vice versa.</li><li>This breaks the <a href="http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode%28%29">Object.hashCode()</a>
contract!</li></ul><li>Adding/Removing fields take more time since you need to
synchronize the change to all boilerplate methods.</li><ul><li>Again, we're
facing the consistency problem.</li></ul><li>These simple classes tend to be very
long and not very readable.</li><li>Boilerplate code makes it harder to find out which methods <strong>don't</strong>
behave the default way.</li><li>Javadoc, if existent, is usually meaningless
(but you might see some banal documentation that doesn't add any real
value).</li><li>Our existing classes are not up to standard!</li></ul><br><span style="font-weight: bold;">So what can be done to remedy the situation?</span><br><br>We could, of course, try to simplify the classes as much as we can and maybe address some of the issues.<br>This won't alleviate the boilerplate code problem altogether, though.<br><br>We could write annotations to do some of the things for us automatically.<br>The easiest approach would be runtime-based, and would hinder performance.<br>This also means we need to maintain this "infrastructure" and all the implications of such a decision.<br><br><br><span style="font-weight: bold;">Luckily, there is a much easier solution: Someone else already did it!</span><br><br>Check out Project Lombok: http://projectlombok.org<br>What Lombok gives us, among some other things, is a way to greatly simplify our POJOs by using annotations to get the boilerplate code automatically generated.<br>This means we get the benefit of annotations which would simplify the code a whole lot, while not imposing a performance cost (since the boilerplate code is generated during compilation).<br>However, it's also possible to create the methods yourself if you want them to behave differently.<br>Outside the POJO itself, you would see it as you would always see it.<br><br>So what are the downsides to this approach?<br><ul><li>First of all, Lombok provides also some other capabilities which I'm not sure are required/wanted at this time.</li><ul><li>That's why I propose we use it for commons project, and make use of it's POJO-related annotations ONLY.</li></ul><li>There might be a problem debugging the code since it's auto-generated.</li><ul><li>I think this is rather negligible, since usually you don't debug POJOs anyway.</li></ul><li>There might be a problem if the auto-generated code throws an Exception.</li><ul><li>As before, I'm rather sure this is an edge-case which we usually won't hit (if at all).</li></ul></ul><br>Even given these possible downsides, I think that we would benefit greatly if we would introduce this library.<br><br>If you have any questions, you're welcome to study out the project site which has very thorough documentation: http://projectlombok.org<br><br>Your thoughts on the matter?<br><br><div><span name="x"></span>Regards,<br>Mike<span name="x"></span><br></div><br></div></body></html>