getter and setter generation with annotations

[nimo frey]

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]

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.

[nimo frey]

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:

class object{

private Integer id;
private String name;

public Integer getId() {return id;}
public String getName() {return name;}


public void setId(Integer id) {this.id = id;}
public void setName(String name) {this.name = name;}

}

or this:

class object{

private Integer id;
public Integer getId() {return id;}
public void setId(Integer id) {this.id = id;}

private String name;
public String getName() {return name;}
public void setName(String name) {this.name = name;}

}

Or do you prefer any other style?

[David Newton]

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]

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]

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]

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]

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]

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]

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:

Getter(Access.public) Setter(Access.private)
private String field;

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]

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]

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.

[David Newton]

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]

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]

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]

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

[nimo frey]

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]

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:

class Thing
{
    //Example property
    Integer Property myProperty = 3;  
}    
    //Example use
    Integer value = myThing.myProperty;

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

class Property<T>
{
    T value;

    Property(T v)
    {
        set(v);
    }

    public void set(T v)
    {
        this.value = v;
    }

    public T get()
    {
        return this.value;
    }
}

class Thing
{
    Property<Integer> myProperty = new Property<Integer>(3);
}

    Integer value = myThing.myProperty.get();

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

    myThing.myProperty

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:

class Thing
{
    Integer Property myProperty = 3
    {
        set(Integer v)
        {
            database.submitNewValue("myProperty", v);
        }
        Integer get()
        {
            return database.getValue("myProperty");
        }
    }
}
    //Client doesn't change...  No broken interface.
    Integer value = myThing.myProperty;

[nimo frey]

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]

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]

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]

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]

http://stackoverflow.com/questions/710266/why-will-there-be-no-native-properties-in-java-7
http://tech.puredanger.com/java7

[Sudarshan Sreenivasan]

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]

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]

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]

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.