Re: [Engine-devel] Simplifying our POJOs

----- 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%2... >>>> 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.

>>> >>>> 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(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel