[Engine-devel] Simplifying our POJOs
Hi,<br><br>Today many <a href=3D"http://en.wikipedia.org/wiki/Plain_Old_Ja= va_Object">POJO</a>s are used throughout the system to convey data:<br><ul>= <li> Parameters - To send data to commands.</li><li> Business E= ntities - To transfer data in the parameters & to/from the DB.</li></ul= These POJOs are (usually) very verbose and full of <a href=3D"http://en.wi= kipedia.org/wiki/Boilerplate_code">boilerplate code</a>.<br><br>This, in tu= rn, reduces their readability and maintainability for a couple of reasons (=
--=_fc18606d-6d0a-46bb-9d9b-34be55a9dcf7 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, Today many POJO s are used throughout the system to convey data: =E2=80=A2 Parameters - To send data to commands. =E2=80=A2 Business Entities - To transfer data in the parameters & to/f= rom the DB. These POJOs are (usually) very verbose and full of boilerplate code . This, in turn, reduces their readability and maintainability for a couple o= f reasons (that I can think of): =E2=80=A2 It's hard to know what does what: =E2=80=A2 Who participates in equals/hashCode? =E2=80=A2 What fields are printed in toString? =E2=80=A2 Consistency is problematic: =E2=80=A2 A field may be part of equals but not hashCode, or vice v= ersa. =E2=80=A2 This breaks the Object.hashCode() contract! =E2=80=A2 Adding/Removing fields take more time since you need to synchronize the cha= nge to all boilerplate methods. =E2=80=A2 Again, we're facing the consistency problem. =E2=80=A2 These simple classes tend to be very long and not very readable. =E2= =80=A2 Boilerplate code makes it harder to find out which methods don't beh= ave the default way. =E2=80=A2 Javadoc, if existent, is usually meaningless (but you might s= ee some banal documentation that doesn't add any real value). =E2=80=A2 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 mayb= e 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 impli= cations 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 g= enerated. 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 c= ode 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? =E2=80=A2 First of all, Lombok provides also some other capabilities wh= ich I'm not sure are required/wanted at this time. =E2=80=A2 That's why I propose we use it for commons project, and m= ake use of it's POJO-related annotations ONLY. =E2=80=A2 There might be a problem debugging the code since it's auto-generated. =E2=80=A2 I think this is rather negligible, since usually you don'= t debug POJOs anyway. =E2=80=A2 There might be a problem if the auto-generated code throws an Exception. =E2=80=A2 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 whi= ch has very thorough documentation: http://projectlombok.org Your thoughts on the matter? Regards, Mike --=_fc18606d-6d0a-46bb-9d9b-34be55a9dcf7 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable <html><head><style type=3D'text/css'>p { margin: 0; }</style></head><body><= div style=3D'font-family: Times New Roman; font-size: 12pt; color: #000000'= that I can think of):<br><ul><li>It's hard to know what does what:</li><ul>= <li>Who participates in equals/hashCode?</li><li>What fields are printed in= toString? <br></li></ul><li>Consistency is problematic:</li><ul><li>= A field may be part of equals but not hashCode, or vice versa.</li><li>This= breaks the <a href=3D"http://docs.oracle.com/javase/6/docs/api/java/lang/O= bject.html#hashCode%28%29">Object.hashCode()</a> contract!</li></ul><li>Adding/Removing fields take more time since you nee= d to synchronize the change to all boilerplate methods.</li><ul><li>Again, we're= facing the consistency problem.</li></ul><li>These simple classes tend to b= e very long and not very readable.</li><li>Boilerplate code makes it harder to fin= d out which methods <strong>don't</strong> behave the default way.</li><li>Javadoc, if existent, is usually meaningle= ss (but you might see some banal documentation that doesn't add any real value).</li><li>Our existing classes are not up to standard!</li></ul><br><= span style=3D"font-weight: bold;">So what can be done to remedy the situati= on?</span><br><br>We could, of course, try to simplify the classes as much = as we can and maybe address some of the issues.<br>This won't alleviate the= boilerplate code problem altogether, though.<br><br>We could write annotat= ions to do some of the things for us automatically.<br>The easiest approach= would be runtime-based, and would hinder performance.<br>This also means w= e need to maintain this "infrastructure" and all the implications of such a= decision.<br><br><br><span style=3D"font-weight: bold;">Luckily, there is = a much easier solution: Someone else already did it!</span><br><br>Check ou= t Project Lombok: http://projectlombok.org<br>What Lombok gives us, among s= ome other things, is a way to greatly simplify our POJOs by using annotatio= ns to get the boilerplate code automatically generated.<br>This means we ge= t the benefit of annotations which would simplify the code a whole lot, whi= le not imposing a performance cost (since the boilerplate code is generated= during compilation).<br>However, it's also possible to create the methods = yourself if you want them to behave differently.<br>Outside the POJO itself= , you would see it as you would always see it.<br><br>So what are the downs= ides to this approach?<br><ul><li>First of all, Lombok provides also some o= ther capabilities which I'm not sure are required/wanted at this time.</li>= <ul><li>That's why I propose we use it for commons project, and make use of= it's POJO-related annotations ONLY.</li></ul><li>There might be a problem = debugging the code since it's auto-generated.</li><ul><li>I think this is r= ather negligible, since usually you don't debug POJOs anyway.</li></ul><li>= There might be a problem if the auto-generated code throws an Exception.</l= i><ul><li>As before, I'm rather sure this is an edge-case which we usually = won't hit (if at all).</li></ul></ul><br>Even given these possible downside= s, I think that we would benefit greatly if we would introduce this library= .<br><br>If you have any questions, you're welcome to study out the project= site which has very thorough documentation: http://projectlombok.org<br><b= r>Your thoughts on the matter?<br><br><div><span name=3D"x"></span>Regards,= <br>Mike<span name=3D"x"></span><br></div><br></div></body></html> --=_fc18606d-6d0a-46bb-9d9b-34be55a9dcf7--
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?
Regards, Mike
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
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?
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. -- /d "Willyoupleasehelpmefixmykeyboard?Thespacebarisbroken!"
--=_049b3bac-d81e-404c-bc87-6670f4066fcd Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit ----- Original Message -----
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
If you're interested in just the effect and don't/can't watch the 3min demo on the site, I attached examples of a class before & after.
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.
As I said these are edge cases which although are important, I'm not sure if we will ever hit them. Also bear in mind that you can still write your own code in the POJO, which will take precedence over the auto generated code, and I believe that for that code the lin numbers will be in-sync.
--
/d
"Willyoupleasehelpmefixmykeyboard?Thespacebarisbroken!"
--=_049b3bac-d81e-404c-bc87-6670f4066fcd Content-Type: text/x-java; name=SimplePerson.java Content-Disposition: attachment; filename=SimplePerson.java Content-Transfer-Encoding: base64 aW1wb3J0IGxvbWJvay5EYXRhOwoKQERhdGEKcHVibGljIGNsYXNzIFNpbXBsZVBlcnNvbiB7CiAg ICBwcml2YXRlIGZpbmFsIFN0cmluZyBnZW5kZXI7Cn0K --=_049b3bac-d81e-404c-bc87-6670f4066fcd Content-Type: text/x-java; name=BolierplatePerson.java Content-Disposition: attachment; filename=BolierplatePerson.java Content-Transfer-Encoding: base64 cHVibGljIGNsYXNzIEJvbGllcnBsYXRlUGVyc29uIHsKICAgIHByaXZhdGUgZmluYWwgU3RyaW5n IGdlbmRlcjsKCiAgICBwdWJsaWMgU3RyaW5nIGdldEdlbmRlcigpIHsKICAgICAgICByZXR1cm4g Z2VuZGVyOwogICAgfQoKICAgIHB1YmxpYyBCb2xpZXJwbGF0ZVBlcnNvbihTdHJpbmcgZ2VuZGVy KSB7CiAgICAgICAgc3VwZXIoKTsKICAgICAgICB0aGlzLmdlbmRlciA9IGdlbmRlcjsKICAgIH0K CiAgICBAT3ZlcnJpZGUKICAgIHB1YmxpYyBpbnQgaGFzaENvZGUoKSB7CiAgICAgICAgZmluYWwg aW50IHByaW1lID0gMzE7CiAgICAgICAgaW50IHJlc3VsdCA9IDE7CiAgICAgICAgcmVzdWx0ID0g cHJpbWUgKiByZXN1bHQgKyAoKGdlbmRlciA9PSBudWxsKSA/IDAgOiBnZW5kZXIuaGFzaENvZGUo KSk7CiAgICAgICAgcmV0dXJuIHJlc3VsdDsKICAgIH0KCiAgICBAT3ZlcnJpZGUKICAgIHB1Ymxp YyBib29sZWFuIGVxdWFscyhPYmplY3Qgb2JqKSB7CiAgICAgICAgaWYgKHRoaXMgPT0gb2JqKQog ICAgICAgICAgICByZXR1cm4gdHJ1ZTsKICAgICAgICBpZiAob2JqID09IG51bGwpCiAgICAgICAg ICAgIHJldHVybiBmYWxzZTsKICAgICAgICBpZiAoZ2V0Q2xhc3MoKSAhPSBvYmouZ2V0Q2xhc3Mo KSkKICAgICAgICAgICAgcmV0dXJuIGZhbHNlOwogICAgICAgIEJvbGllcnBsYXRlUGVyc29uIG90 aGVyID0gKEJvbGllcnBsYXRlUGVyc29uKSBvYmo7CiAgICAgICAgaWYgKGdlbmRlciA9PSBudWxs KSB7CiAgICAgICAgICAgIGlmIChvdGhlci5nZW5kZXIgIT0gbnVsbCkKICAgICAgICAgICAgICAg IHJldHVybiBmYWxzZTsKICAgICAgICB9IGVsc2UgaWYgKCFnZW5kZXIuZXF1YWxzKG90aGVyLmdl bmRlcikpCiAgICAgICAgICAgIHJldHVybiBmYWxzZTsKICAgICAgICByZXR1cm4gdHJ1ZTsKICAg IH0KCiAgICBAT3ZlcnJpZGUKICAgIHB1YmxpYyBTdHJpbmcgdG9TdHJpbmcoKSB7CiAgICAgICAg cmV0dXJuICJQZXJzb24gW2dlbmRlcj0iICsgZ2VuZGVyICsgIl0iOwogICAgfQp9Cg== --=_049b3bac-d81e-404c-bc87-6670f4066fcd--
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) ?
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.
----- 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
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%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.
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.
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
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%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.
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@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
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%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.
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 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@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
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: engine-devel@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%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.
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@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
_______________________________________________ Engine-devel mailing list Engine-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel
----- Original Message -----
----- Original Message -----
From: "Livnat Peer" <lpeer@redhat.com> To: "Yair Zaslavsky" <yzaslavs@redhat.com> Cc: engine-devel@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%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.
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?
Since we don't use JAXB annotations any more that's not an issue. However, you could keep the getters with annotations in place if you need and lombok will not generate them for you.
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@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
_______________________________________________ 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
participants (5)
-
Doron Fediuck -
Laszlo Hornyak -
Livnat Peer -
Mike Kolesnik -
Yair Zaslavsky