Re: [Engine-devel] Simplifying our POJOs

From: "Livnat Peer" <lpeer(a)redhat.com&gt; To: "Yair Zaslavsky" <yzaslavs(a)redhat.com&gt; Cc: engine-devel(a)ovirt.org Sent: Wednesday, February 1, 2012 8:16:34 AM Subject: Re: [Engine-devel] Simplifying our POJOs 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%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. >> > 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(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 >> > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel