[Engine-devel] Simplifying our POJOs
Yair Zaslavsky
yzaslavs at redhat.com
Wed Feb 1 07:13:05 UTC 2012
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
>
More information about the Devel
mailing list