File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Java in General and the fly likes getter and setter generation with annotations Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of The Java EE 7 Tutorial Volume 1 or Volume 2 this week in the Java EE forum
or jQuery UI in Action in the JavaScript forum!
JavaRanch » Java Forums » Java » Java in General
Bookmark "getter and setter generation with annotations" Watch "getter and setter generation with annotations" New topic
Author

getter and setter generation with annotations

nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
I discovered lombok which uses annotations to generate getters and setters. http://projectlombok.org/index.html

Is this recommended?

Another question is:

Is it better to make all the fields which should be accessed by other objects public
and access fields instead of getters/setters - encapsulation is therefore secured?
So I do not need to write that boilerplate code an do not need something like lombok.

I guess, in scala or ruby, there is also only fields.

So are there any good reason why I need getter/setter?
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1761
    
    7

A misuse of annotations, in my opinion. Those annotations are certainly beyond what I would classify as simple metadata.
I view it as little more than an attempt at solving problems that should be addressed by the platform itself (if at all!) i.e. properties and resource management (from what I've seen in the video).
And no, I definitely wouldn't abandon accessors/mutators in favor of public fields, for reason that should be obvious.
I wouldn't add them unnecessarily either - certainly not to classes that needn't conform to the JavaBean specification.

Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
JavaBean specification, I know.

than an attempt at solving problems that should be addressed by the platform itself (if at all!)


I understand. However, why do new languages such as scala or ruby ommit get/set? Why make maintanance harder than it is? Without getter/setter code shrinks and it is much cleaner.


By the way, which style do you prefer?

this:




or this:



Or do you prefer any other style?
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Properties go at the top of a class file. Simple accessors go at the bottom. Properties are important. Simple getters and setters are not.

I think Lombok is a great solution to a problem, but last I checked it only works in Eclipse and under build tools--I use IntelliJ, so no help for me there.

I don't understand the objection made by Jelle--other tools do byte-code modification based on annotations, although more commonly at load time. It'd be great it the problem was solved by the platform itself, but it isn't: sometimes we must take matters into our own hands.
nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
I also think Lombok is great and frees us from boilerplate getter/setters. The code is much easier to overview and we can specify the package-level in a clean way.

I hope to see more such solutions in a IDE-independent-way.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1761
    
    7

David Newton wrote:
I don't understand the objection made by Jelle


I'll admit my objection is motivated mainly by my fear and loathing of annotation hell.
It seems like every framework in existance can't wait to jump on the annotation bandwagon, whether that's a suitable choice or not.
Sure, annotations have their uses, but I think using them to dynamically generate code is "not as was intended".
Clearly, if code generation gets even a little complex the amount of annotation code required blows up quite rapidly.
To me it seems most of the code generation features offered by Lombok are usable only if you require little or no flexiblity.
Moreover, I think the "trivial boilerplate" code it generates isn't nearly always that trivial and does require careful consideration.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Sorry, but I believe getters and setters pretty much fall into the brain-numbingly trivial. Java chooses not to have real properties--why should I suffer from that choice?

Annotating a property with @Getter and @Setter is about as drop-dead simple as you can get, both source-wise, and implementation-wise.

And given the option between a bunch of annotations, and 10x+ as much code, I'll take annotations any day of the week.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1761
    
    7

David Newton wrote:Sorry, but I believe getters and setters pretty much fall into the brain-numbingly trivial. Java chooses not to have real properties--why should I suffer from that choice?

Annotating a property with @Getter and @Setter is about as drop-dead simple as you can get, both source-wise, and implementation-wise.

And given the option between a bunch of annotations, and 10x+ as much code, I'll take annotations any day of the week.


Alright, case in point, EclipseLink indirection. In my current project this impacts the bulk of the setters / getters in all of the domain objects.
By no means making them complex, but they deviate enough from a "de facto" implementation to render Lombok generation 100% useless.
Also, because Lombok is yet another framework that uses annotation the risk of 10x+ as much annotations as code is what I worry about.

David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Who said Lombok was a general-purpose solution? For the bulk of simple getters/setters it's perfectly fine. If you're using a framework that has other getter/setter implementations, then they're not simple getters and setters, and Lombok isn't appropriate--seems pretty straight-forward to me.

So you'd rather write all the code that annotations handle for you--that's fine; nothing wrong with that. I have things I'd rather work on instead, that's all.
nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
Let me explan it with Muda (http://en.wikipedia.org/wiki/Muda_%28Japanese_term%29)

I cite:

..is a traditional Japanese term for an activity that is wasteful and doesn't add value or is unproductive..


getters/setters are wasteful and are unproductive for maintanance.

It is far better to have something like this:



It is easier for eyes and we can change the modifier directly with a single word without plumbing the whole getter/setter method.
It saves time and space with only one line of annotation, instead of x lines of getter/setter of that property. It is far better!

By the way, other (dynamic) languages (Ruby or Scala) omit getter/setters completely. It is noise.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

nimo frey wrote:By the way, other (dynamic) languages (Ruby or Scala) omit getter/setters completely. It is noise.

Well, to be fair, that's not entirely accurate: other languages support real properties, where explicit getters and setters are optional. When an accessor needs its own functionality, it can be provided.

The lack of real properties is one example of Java's noise-over-substance I find particularly galling. While I don't use Lombok, I don't have any philosophical issues with it--after all, I use any number of other load- and compile-time byte-code manipulation tools, driven by annotations, framework support, and so on. I don't see any real difference between any of those and things like Lombok.
Wouter Oet
Saloon Keeper

Joined: Oct 25, 2008
Posts: 2700

I don't really see the problem with getters and setters. Any ide can generate them for you. It takes 9 key strokes to generate 2 getters and setters with IntelliJ. That even less then the "@Setter @Getter" for 1. Although I see why you would want to make the code more expressive, getters and setters are usually at the bottom of the file and are folded (code folding in the ide). So in my opinion they're not in the way. And this just adds another dependency to your project.


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand." --- Martin Fowler
Please correct my English.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

The problem is that they are unnecessary noise, folded or not. (Besides that I don't just look at code in environments that provide folding.)

It's not a matter of keystrokes, it's not a matter of whether or not they can be automatically generated, it's a matter of elegance, purpose, and meaning.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1761
    
    7

What about documentation? The JavaDoc tool doesn't (ok - shouldn't) generate API documentation for private members, so the public accessors are the only suitable way of adding a meaningful description of what a ""property" represents in the domain, what its legal values are, deprecation information, an instance' serialized representation, locking information etc.
Ok, maybe a bit of a nitpick, but then again not really a reach either. In any case, I think labelling accessors as purely noise is somewhat of generalization.
But getters/setters are the most "trivial" of the "noisy" methods that this framework can generate for you - what about hashCode() equals() and toString()?
And the concurrency mechanisms? Oh my. Let's not go there...

Anyway, I guess what I'm trying to convey is that I believe that a practial and usable code generation mechanism should be flexible, making it inherently complex. That complexity, in my opinion, makes the annotation mechanism an ill-suited choice, because I feel it will necessitate the use of an impractical, or at the very least uncomfortable, amount of annotation code.
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Jelle Klap wrote:What about documentation? The JavaDoc tool doesn't (ok - shouldn't) generate API documentation for private members, so the public accessors are the only suitable way of adding a meaningful description of what a ""property" represents in the domain, what its legal values are, deprecation information, an instance' serialized representation, locking information etc.

And again: if you need to add all this information to a simple getter/setter, it's no longer a simple getter/setter, and shouldn't be treated as such.

Lombok's @Getter/@Setter annotations serve a specific purpose. If they don't suit the problem, don't use them--not rocket surgery.
I think labelling accessors as purely noise is somewhat of generalization.

Of course it is--and generally it's correct.
But getters/setters are the most "trivial" of the "noisy" methods that this framework can generate for you - what about hashCode() equals() and toString()?

Again: if they don't suite your needs, don't use them--I don't see what the big deal is. If you need custom functionality, then write it!
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

David Newton wrote: ... not rocket surgery...

Rocket surgery sure is hard - you gotta have quick reflexes with the rocket-powered scalpel and the dangers in using rocket-assisted suction are well documented :-)


(or did you mean surgery on rockets...)


Steve
nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
Well, to be fair, that's not entirely accurate: other languages support real properties, where explicit getters and setters are optional. When an accessor needs its own functionality, it can be provided.




I do not understand this:
Why does ruby or scala developers prefer using field based access, if it is a bad programming style (encapsulation or the like) ?

(By the way, Ruby or scala code looks so much smaller and cleaner (besides eliminating the getters/setters) as java and I do not really know, why I have to write so much when a ruby developer writes lesser with the same effect.)
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4181
    
  21

nimo frey wrote:
Well, to be fair, that's not entirely accurate: other languages support real properties, where explicit getters and setters are optional. When an accessor needs its own functionality, it can be provided.




I do not understand this:
Why does ruby or scala developers prefer using field based access, if it is a bad programming style (encapsulation or the like) ?


You mis-understand Properties. Properties are not akin to field based access, they are more like providing a class with implicit get() and set() methods. So for example:

'Behind the scenes' the propery works more like this...


You just don't see all the extra code. With true Properties, even though you access the value like:

You are actually calling an implicit get() or set() method, and as such you could override the set() / get() method without changing the external call:

nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
they are more like providing a class with implicit get() and set() methods.


okay got it, thank you!

I was wondering about ruby or scala code which makes extensive use of fields (for example, objects which has only fields).

David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

nimo frey wrote:I was wondering about ruby or scala code which makes extensive use of fields (for example, objects which has only fields).

It's probably best to call them "properties", since that's the canonical term. "Fields" doesn't really describe the underlying access mechanisms, at least in my opinion. And they don't make any heavier use of them than any other language, they just provide *real* property support, unlike Java.
Gupta Tarun
Greenhorn

Joined: Sep 16, 2010
Posts: 22


A question regarding writing annotation based getters and setters - let's say I want to search usage of a certain property of a bean accross the projects in eclipse. will it allow me to search the usages (keeping the namespace intact) ? I mean I don't want text search.
nimo frey
Ranch Hand

Joined: Jun 28, 2008
Posts: 580
will it allow me to search the usages (keeping the namespace intact)


yes, only if the Lombok does support your IDE (actually Eclipse, Netbeans are supported). Intellij in future.

Execute lombok.jar and follow the instruction, it will configure your IDE in one step.


It's probably best to call them "properties", since that's the canonical term.


really? I have thought, that we distinguish of field based access and property (getter/setter) access. For example, in JPA the access mode can be distinguished of Field Access and Property Access. So there is a strict definition according to specification.


they just provide *real* property support, unlike Java.


I do not understand that.
Kalpesh Soni
Ranch Hand

Joined: Jan 02, 2001
Posts: 312
http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7
http://tech.puredanger.com/java7


Test 094, IBM WID 6.0 cert
SCJP 1.2
SCBCD 1.3 Beta
SCWCD 1.4 Beta
SCMAD Beta
SCDJWS Beta

KS
Sudarshan Sreenivasan
Ranch Hand

Joined: Jun 28, 2007
Posts: 188

Hi,

I use hibernate for my persistence, I use annotations as the way to specify the meta data, I further place the annotations on the getter methods , so that it is easier to debug the same.

How to i combine the use of lombak with hibernate ?

Thanks
Sudarshan
David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

You don't--how can you annotate a method that doesn't exist?

You *might* be able to do some byte-code manipulation, or figure out a way to make Hibernate apply its annotations to the methods after Lombok generates the accessors, but IMO the effort really wouldn't be worth it.
Sudarshan Sreenivasan
Ranch Hand

Joined: Jun 28, 2007
Posts: 188

Hi,

That is what i thought too, was just confirming it, however this seems to be like a limitation for adopting lombak what say ?
Roel Spilker
Greenhorn

Joined: Oct 08, 2010
Posts: 1
David Newton wrote:You don't--how can you annotate a method that doesn't exist?

You *might* be able to do some byte-code manipulation, or figure out a way to make Hibernate apply its annotations to the methods after Lombok generates the accessors, but IMO the effort really wouldn't be worth it.


As one of the developers of Lombok I can tell you that we're currently working on extending the @Getter and @Setter annotations to allow for annotations to be placed on the generated methods or method parameters.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: getter and setter generation with annotations