JavaBeans™ should be extended to reduce bloat

Posted on by lukaseder
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 by lukaseder

I made jOOQ

8 thoughts on “JavaBeans™ should be extended to reduce bloat”

    1. Really? You mean the fact that “void-methods” can be chained? That would be quite interesting to see. Do you have any reference for this?

      Reply

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

    Reply

    1. 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…

      Reply

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

        Reply

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

          Reply

Leave a Reply