[Engine-devel] Simplifying our POJOs

[Livnat Peer]

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%28%29>
>         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
> 
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel