1:02 p.m.
--=_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'=
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 (=
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--