[Engine-devel] Simplifying our POJOs

Wed Feb 1 07:16:34 UTC 2012

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

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