I am the founder and CEO of Data Geekery GmbH, located in Zurich, Switzerland. With our company, we have been selling database products and services around Java and SQL since 2013. Ever since my Master's studies at EPFL in 2006, I have been fascinated by the interaction of Java and SQL. Most of this experience I have obtained in the Swiss E-Banking field through various variants (JDBC, Hibernate, mostly with Oracle). I am happy to share this knowledge at various conferences, JUGs, in-house presentations and on our blog. Lukas is a DZone MVB and is not an employee of DZone and has posted 249 posts at DZone. You can read more from them at their website. View Full User Profile

JavaBeans™ Should be Extended to Reduce Bloat

11.01.2012
| 3446 views |
  • submit to reddit

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!

 

 

 

 

 

 

 

Published at DZone with permission of Lukas Eder, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

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:

 
@Property String name
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.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.