Re: [Engine-devel] Simplifying our POJOs

On 31/01/12 12:02, Mike Kolesnik wrote: > Hi, > > Today many POJO <http://en.wikipedia.org/wiki/Plain_Old_Java_Object>s > are used throughout the system to convey data: > > * Parameters - To send data to commands. > * Business Entities - To transfer data in the parameters & to/from > the DB. > > These POJOs are (usually) very verbose and full of boilerplate code > <http://en.wikipedia.org/wiki/Boilerplate_code>;. > > This, in turn, reduces their readability and maintainability for a > couple of reasons (that I can think of): > > * It's hard to know what does what: > o Who participates in equals/hashCode? > o What fields are printed in toString? > * Consistency is problematic: > o A field may be part of equals but not hashCode, or vice versa. > o This breaks the Object.hashCode() > <http://docs.oracle.com/javase/6/docs/api/java/lang/Object.html#hashCode%2... > contract! > * Adding/Removing fields take more time since you need to synchronize > the change to all boilerplate methods. > o Again, we're facing the consistency problem. > * These simple classes tend to be very long and not very readable. > * Boilerplate code makes it harder to find out which methods *don't* > behave the default way. > * Javadoc, if existent, is usually meaningless (but you might see some > banal documentation that doesn't add any real value). > * Our existing classes are not up to standard! > > > So what can be done to remedy the situation? > > We could, of course, try to simplify the classes as much as we can and > maybe address some of the issues. > This won't alleviate the boilerplate code problem altogether, though. > > We could write annotations to do some of the things for us automatically. > The easiest approach would be runtime-based, and would hinder performance. > This also means we need to maintain this "infrastructure" and all the > implications of such a decision. > > > Luckily, there is a much easier solution: Someone else already did it! > > Check out Project Lombok: http://projectlombok.org > 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. > 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). > However, it's also possible to create the methods yourself if you want > them to behave differently. > Outside the POJO itself, you would see it as you would always see it. > > So what are the downsides to this approach? > > * First of all, Lombok provides also some other capabilities which I'm > not sure are required/wanted at this time. > o That's why I propose we use it for commons project, and make use > of it's POJO-related annotations ONLY. > * There might be a problem debugging the code since it's auto-generated. > o I think this is rather negligible, since usually you don't debug > POJOs anyway. > * There might be a problem if the auto-generated code throws an Exception. > o As before, I'm rather sure this is an edge-case which we usually > won't hit (if at all). > > > Even given these possible downsides, I think that we would benefit > greatly if we would introduce this library. > > If you have any questions, you're welcome to study out the project site > which has very thorough documentation: http://projectlombok.org > > Your thoughts on the matter? > - I think an example of before/after pojo would help demonstrating how good the framework is. - Would it work when adding JPA annotations? > Regards, > Mike >