[Engine-devel] Simplifying our POJOs

[Livnat Peer]

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.


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