Re: [Engine-devel] Simplifying our POJOs

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

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