Eclipse or IntelliJ typically generate getters and setters this way:
public class Month {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
And we all complain because that consumes a lot of screen space (9 lines). Provided that the trio attribute / getter / setter really represents a unique property, why not generate it that way?
public class Month {
public String getName() { return this.name; }
public void setName(String name) { this.name = name; }
private String name;
}
That’s much more compact (3 lines, ie a third of what we had) and put all related constructs as a single block. You can also mutualize the JavaDoc for free 
What do you think?
Oh and please don’t tell me about Scala, Groovy or Fantom, we all know Java should have had first-class properties. But that’s life.
that would make the code formatting strategy provided by the IDE a little bit tricky and non uniform.
I speak for myself, I won’t do that because I prefer a clear code to a space optimized code.
I put getters/setters that are trivial methods at the end of the file.
my 2 cents.
That’s the point. In a way, a getter / setter is not a method, it’s a part of the property construct
Hi Emmanuel.
Does it really make a difference? Shouldn’t we try to avoid setters and/or getters altogether.
David.
Properties are fundamental constructs in virtually all modern OO languages, not sure why you want to avoid them
Besides, a getter/setter has practical advantages over raw attributes in Java for all proxy-based frameworks.
Just use Groovy, and do:
class Month {
String name
}
Grou quoi?
What’s the advantage if after compilation it will have the same effect? For code formatting shouldn’t matter more legibility to ease maintenance?
Besides, the only advantage that would really matter – unified javadoc – will only work if others have access to your code, generated javadoc will not automatically propagate it to all of the methods and properties, would it?
One of the advantage I see is readability. It’s more readable than having the attribute and it’s corresponding getter on opposite sides of the .java.
Another solution would be for IDEs to hide the “redundant” getter / setter and display the attribute differently (assuming the JavaBean conventions are respected). For some weird reasons, they don’t.
This is indeed an endless debate. I tend to think that immutable objects remove the need of 95% of the setters. And most of the getters break the ‘tell don’t ask rule’ making code more difficult to maintain.
Anybody has experience with lombok? http://projectlombok.org/
Are there any drawbacks? If not, wouldn’t this solve the “problem”?
@Guillaume Laforge :
Or use scala and type :
class Month (var name : String)
I won, one line… (don’t hit meeeeeeee)
@emmanuel
For simple accessors, what do you think of an annotation that will generate accessors, like @Property or something like that.
Eclipse 3.5 and Netbeans 6.9 (what about IntelliJ ?) now support apt in editor, so generated accessors are available in autocompletion and navigation.
By the way i just listened the new Les Cast Codeurs episode, a good episode guys, and vive les mitaines
Oups I clicked on Arnauld Van Muysewinkel’s link just after submitting my comment. So obviously my questions are higly related to his.
Lombok seems to be a good tool, i’ll give it a test.
That’s an OK solution I guess. The main problem is that from what Julien Viet told me, you need Sun’s JVM as you need apt specific classes and not the standard Annotation Processor of JDK 6
To generate the getter/setters like you suggested means adding a exception to how we format methods. It’s not just the IDEs there also other code formatter tools. In my opinion this would just add complexity to build tools, IDEs.
Like you wrote, Java should have better support for properties like Groovy…
Lombok is an awsome tool that does this for you.
We are using it extensively. However, it does require Java 6 (not exactly true, because you can compile using Java 6 but target java 5)
One thing which irks me about property get/setters is how they mess up single stepping. I wrote an enhancement for the Eclipse JDT debugger, but it wasn’t picked up