Re: [Engine-devel] Simplifying our POJOs

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

> >>>>> >>>>>> 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 >