[Engine-devel] Simplifying our POJOs

[Yair Zaslavsky]

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

> 
>>>>>
>>>>>> 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
>