Re: [Engine-devel] Simplifying our POJOs

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