[Engine-devel] Simplifying our POJOs

Mike Kolesnik mkolesni at redhat.com
Mon Feb 6 07:59:57 UTC 2012 

----- Original Message -----
> 
> 
> ----- Original Message -----
> > From: "Livnat Peer" <lpeer at redhat.com>
> > To: "Yair Zaslavsky" <yzaslavs at redhat.com>
> > Cc: engine-devel at ovirt.org
> > Sent: Wednesday, February 1, 2012 8:16:34 AM
> > Subject: Re: [Engine-devel] Simplifying our POJOs
> > 
> > On 01/02/12 09:13, Yair Zaslavsky wrote:
> > > On 02/01/2012 08:59 AM, Livnat Peer wrote:
> > >> On 01/02/12 08:03, Mike Kolesnik wrote:
> > >>>
> > >>> ----- 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.
> > >>>
> > >>
> > >> Since this package is required only during compile time it is
> > >> relatively
> > >> easy to push it in.
> > >> Need to make sure it is working nice with debugging and give it
> > >> a
> > >> try.
> > >>
> > >> I like this package,
> > >> +1 from me.
> > >>
> > > Another issue to check - (I'm sure it does, but still) -
> > > Are empty CTORs generated as well? (There is a long debate for
> > > POJOs
> > > that contain X fields whether they should have an empty CTOR, as
> > > usage
> > > of empty CTOR may yield to potential bugs (logically speaking) of
> > > "partial state") - Unfortunately, some frameworks require
> > > existence
> > > of
> > > empty CTOR (I admit, still haven't look at the site thoroughly,
> > > so
> > > I'm
> > > just sharing here thoughts of what should we check for).
> > > 
> > > 
> > > Yair
> > > 
> > 
> > It seems like you can define what ever you like -
> > @NoArgsConstructor,
> > @RequiredArgsConstructor
> > @AllArgsConstructor
> 
> I am keeping an eye on project lombok for a good while and I really
> like it's approach, but I have never seen it in a production app so
> far. Could be interesting to give it a try!
> 
> Just one more thing I would like to know about annotations: some
> frameworks (jaxb for example) require you to place the annotations
> on the getters (creating a hell of annotations). Fortunately the
> model classes are not serialized by the rest api as far as I know,
> but would it work together with lombok?

Since we don't use JAXB annotations any more that's not an issue.
However, you could keep the getters with annotations in place if you need and lombok will not generate them for you.

> 
> Btw... Vojtech has a similar project to simplify resource file
> generations in the frontend.
> http://code.google.com/p/genftw/
> 
> Laszlo
> 
> > 
> > Livnat
> > 
> > >>
> > >>>>>>
> > >>>>>>> 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
> > >>>>
> > >>> _______________________________________________
> > >>> Engine-devel mailing list
> > >>> Engine-devel at ovirt.org
> > >>> http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >>
> > > 
> > 
> > _______________________________________________
> > Engine-devel mailing list
> > Engine-devel at ovirt.org
> > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>

More information about the Engine-devel mailing list