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!

Tags: , , , , , , , , , ,

8 responses to “JavaBeans™ should be extended to reduce bloat”

  1. lstachowiak says :

    As far as I can remember this was actually proposition for java 7 specification. I don’t know if it was moved to java 8.

  2. Eric S says :

    I think you are effectively asking a void return type to mean a return type of the class itself, and “return;” to effectively mean “return this;”. I suspect there are more implications of such a change than just the ability to chain method invocations.

    I wouldn’t be at all surprised if there were already a request for such a feature in the Java bug database along with a discussion of this. However there seems to be no way to do a usefully advanced search in there at the moment (I assume because they are in the middle of migrating it to Jira).

    • lukaseder says :

      I don’t think that such a change should influence “Java-the-Platform”, i.e. the JVM. It should just be syntactic sugar within “Java-the-Language”. In other words, given my example:

      // This Java source code ...
      int x = api.oneMethod()
                 .anotherMethod()
                 .x;   
      
      // ... should effectively be translated to this 
      // equivalent Java source code by the compiler:
      api.oneMethod();
      api.anotherMethod();
      int x = api.x;
      

      This change shouldn’t have any side-effects or other implications, as far as I can see. Or what did you have in mind?

      btw: Nice to know that Oracle finally abandons that horrible bug tracking system…

      • ericjs says :

        Syntactic sugar is fine, but it needs to be consistent with existing syntax.

        api.oneMethod().anotherMethod()

        implies that oneMethod() is returning api, given how the expression syntax works. To instead say the compiler will treat .anotherMethod() as meaning something different depending on what comes before would be introducing an inconsistency into the overall expression syntax which would not be a good thing, IMO.

        • lukaseder says :

          Changes to the JLS are inevitable, agreed. Then again, consider this extract:

          15.8. Primary Expressions
          
          Primary:
              PrimaryNoNewArray
              ArrayCreationExpression
          
          PrimaryNoNewArray:
              [...]
              MethodInvocation
          
          15.12. Method Invocation Expressions
          
          MethodInvocation:
              [...]
              Primary . NonWildTypeArgumentsopt Identifier ( ArgumentListopt )
          

          There’s not much in the grammar, that would prevent such a feature. Let’s look at the rules applied to the grammar:

          15.12.1. Compile-Time Step 1: Determine Class or Interface to Search
          
          If the form is Primary . NonWildTypeArgumentsopt Identifier, then the name of the method is the Identifier.
          Let T be the type of the Primary expression. The class or interface to be searched is T if T is a class or interface type, or the upper bound of T if T is a type variable.
          It is a compile-time error if T is not a reference type.
          

          That last sentence would have to be changed, as “void” is not a reference type. I think the change to the JLS would be straight-forward. I can even imagine that the change to the compiler would be quite simple.

          Relevant JLS section:
          http://docs.oracle.com/javase/specs/jls/se7/html/jls-15.html#jls-15.12

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 1,955 other followers

%d bloggers like this: