[Engine-devel] Simplifying our POJOs
Laszlo Hornyak
lhornyak at redhat.com
Thu Feb 2 09:30:25 UTC 2012
----- 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?
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
>
More information about the Devel
mailing list