[Engine-devel] Simplifying our POJOs

[Mike Kolesnik]

----- Original Message -----
> On 01/31/2012 12:45 PM, Doron Fediuck wrote:
> > On 31/01/12 12:39, Livnat Peer wrote:
> >> 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?
> I suspect that yes (needs to be checked)
> Will it work with GWT (if we create new business entity that needs to
> be
> exposed to GWT guys) ?

As it is stated on the site, it supports GWT.

> >>
> >>> Regards,
> >>> Mike
> >>>
> > 
> > Watching the demo it looks like we'll get less code, which in many
> > cases is a good thing.
> > What I'm concerned about is traceability; or- how can we track
> > issues coming from the field
> > when function calls and line numbers in the stack trace will not
> > match the code we know.
> > 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>