[Engine-devel] Simplifying our POJOs
Yair Zaslavsky
yzaslavs at redhat.com
Tue Jan 31 18:40:38 UTC 2012
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) ?
>>
>>> 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.
>
More information about the Engine-devel
mailing list