3:14 p.m.
--=_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%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
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--