Re: [Engine-devel] Simplifying our POJOs

----- Original Message ----- > 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 I am keeping an eye on project lombok for a good while and I really like it's approach, but I have never seen it in a production app so far. Could be interesting to give it a try! Just one more thing I would like to know about annotations: some frameworks (jaxb for example) require you to place the annotations on the getters (creating a hell of annotations). Fortunately the model classes are not serialized by the rest api as far as I know, but would it work together with lombok?

Btw... Vojtech has a similar project to simplify resource file generations in the frontend. http://code.google.com/p/genftw/ Laszlo > > 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 > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel