----- 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%28%29> > >>> 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. > >> > >>> 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@ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel