Re: [Engine-devel] Simplifying our POJOs

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?

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