JavaBeans™ Should be Extended to Reduce Bloat
JavaBeans™ has been around for a long time in the Java world. At some point of time, people realised that the concept of getters and setters was good to provide some abstraction over “object properties”, which should not be accessed directly. A typical “bean” would look like this:
public class MyBean {
private int myProperty;
public int getMyProperty() {
return myProperty;
}
public void setMyProperty(int myProperty) {
this.myProperty = myProperty;
}
}
In various expression languages and other notations, you could then access “myProperty” using a simple property notation, which is good:
// The below would resolve to myBean.getMyProperty() myBean.myProperty // This could resolve to myBean.setMyProperty(5) myBean.myProperty = 5
Critique on Java properties
Other languages, such as C# even allow to inline such property expressions in regular C# code, in order to call getters and setters. Why not Java?
Getter and Setter naming
Why do I have to use those bloated “get”/”is” and “set” prefixes every time I want to manipulate object properties? Besides, the case of the first letter of the property changes, too. If you want to perform a case-sensitive search on all usage of a property, you will have to write quite a regular expression to do so
Setter returning void
Returning void is one of the biggest reasons Java generates so much bloat at API call sites. Since the early days of Java, method chaining was a wide-spread practice. No one would like to miss StringBuilder’s (or StringBuffer’s) chainable append() methods. They’re very useful. Why doesn’t the Java compiler allow to re-access the property container after calling a setter?
A better Java
In other words, this API:
public interface API {
void oneMethod();
void anotherMethod();
void setX(int x);
int getX();
}
Should be usable as such:
API api = ...
int x = api.oneMethod() // Returning void should in fact "return" api
.anotherMethod() // Returning void should in fact "return" api
.x; // Getter access, if x is not accessible
Let’s make this a JSR!
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)
Comments
Liam Knox replied on Fri, 2012/11/02 - 6:08am
Is this a serious article? Returning something though you declare a void? I suppose if you want to take part in an obfuscated language design competition this is a good start. Please leave Java Beans as they are, well understood and defined however bloated you feel they are.
Jonathan Fisher replied on Fri, 2012/11/02 - 11:58am
Javabeans are boilerplate, no one will argue that. I'd rather see a "convention over configuration" type solution, something like new keywords:
class MyObj{ public String s; public writeable String w; public readable String r; // sets the value of s setter s (String s) { this.s = s.trim(); } //returns the value of s getter s () { return s.subString(0,10); } // sets the value of w setter w (String w){ this.w = w.someFunction(); } }
Here the s getters/setters are overridden upon variable access. S has no protection from reads/writes.
The variable w and r will be protected from writes / reads respectively, and the getter/setter methods could be overridden.
Loren Kratzke replied on Fri, 2012/11/02 - 6:52pm
in response to:
Jonathan Fisher
This whole article and thread is kind of weird. Getters and setters are about more than getting and setting (r/w). If you want to access a variable directly then nobody is stopping you. Make it public and have a nice day.
But personally I hate seeing this().that().theOther().thisAgain().... type of programming style. For one thing it makes stack traces almost useless and debugging a bit trickier. It doesn't run faster and is usually harder to read. It's not like lines actually cost anything and compressing multiple lines into one saves time, money, effort, clarity, or anything. Possibly the exact opposite. There are plenty of other opportunities to aggregate multiple method calls into one call, or several poorly written lines into fewer more concise lines.
Nothing can be simpler than a getter and a setter. Why anybody would want to mess with that is beyond me. Get it, set it, forget it. Solving real world problems, now that is where the challenge is.
Lukas Eder replied on Sat, 2012/11/03 - 2:47am
in response to:
Loren Kratzke
Java 8 is a great step forward towards less boilerplate code. Other languages have already embraced the idea of increasing their expressiveness by allowing to write more with less code. Getters / Setters are just one example (see again C#, Scala). Method chaining will be a fundamental part of Java 8's improved Collections API as can be seen in Brian Goetz's article "State of the Collections":
http://cr.openjdk.java.net/~briangoetz/lambda/collections-overview.html
Yes, this is all new and not the way we're used to in Java. But I trust that the expert groups will make the right decisions, and improving bean handling is clearly something that would add further value to Java - maybe, but not necessarily in the way proposed here...
Jonathan Fisher replied on Sat, 2012/11/03 - 10:35am
in response to:
Loren Kratzke
Right, most JVMs will inline getter/setters anyway, so the point wasn't about speed. The point was getting rid of having to right click in Eclipse and hit "Generate getters/setters"... 80% of the time, your getters/setters just return or set a variable. The keyword I proposed take the 80% use-case and make it the norm...
So
myObj.s = "hello!";
would invoke the setter.
anotherVariable = myObj.s;
would invoke the getter. This 'hides' the implementation better than get/set in my mind, because you really don't know if there is a getter/setter, and you really don't/shouldn't care.
Liam Knox replied on Sat, 2012/11/03 - 4:55pm
in response to:
Jonathan Fisher
If you seriously have a gripe about accessing properties via methods vs. a standard convention of encapsulation then I would suggest using another language, maybe C is flexible enough for random access of data.
Lukas Eder replied on Mon, 2012/11/05 - 3:27am
in response to:
Liam Knox
Jonathan's idea involving annotations is not so uncommon or unorthodox. Code generation tools such as Xtend uses similar features. With this Xtend code:
you'll get this Java code :private String name; public String getName() { return this.name; } public void setName(String name) { this.name = name; }Taken from here:
http://blog.efftinge.de/2012/10/introducing-active-annotations.html
Project Lombok also knows similar annotations:
http://projectlombok.org/
An example:
http://projectlombok.org/features/Data.html
Loren Kratzke replied on Mon, 2012/11/05 - 4:47pm
in response to:
Jonathan Fisher
You must either sacrifice one dimension of scope/encapsulation or replace it with new functionality. It also confuses the currently simple model.
If I have two instances of a class, and the class has a private member, I have direct access to the member from one class to the other without using an accessor and I can also have a public method for use by the rest of the world (and the opportunity to insert code there). How would I retain direct access from instances of the same class if direct access now automagically routes through the accessors? It is not a use case that occurs often, but would be torpedoed by the hiding scheme. Net result is less flexibility and possibly the requirement of a new annotation or keyword that states that the member indeed can be accessed by other instances of the same class without an accessor.
Not a big deal but programming language features need to be thought all the way through. Personally, I like the button that generates accessors. It is easy enough to use and the language remains simple with fewer assumptions. What you see is what you get.