Take the 2-minute tour ×

Just a little question i had trouble googling the answer too.

Is it possible to do something like..


bomb is just an object with methods setX and setY, i was just wondering if you could string method invocations together somehow to save space and make things more human readable? I'm sure i've seen something similar before..

Oh cruicially i'm working in java here. Though I would be interested to know if such a shorthand exists in c++ too if anyone knows :)

share|improve this question
Great answers thank you folks, i understand what's going on much better now. So is returning an object in simple setter methods worth doing for this kind of use or a bit wasteful? or perhaps the difference is negligible ? –  Holly Jan 7 '12 at 16:15
The difference amounts to pusing this onto the stack, but this had to be done anyway if you call a second method. So the only "waste" is that the object reference will have to be popped off the stack after the last call. –  Ingo Jan 7 '12 at 16:22
Yes as the answers below indicate, but the methods are executed right to left one after each other. They do not execute 'at once' or in parallel. It's basically syntax-sugar to save typing 'bomb.' again –  kenny Jan 7 '12 at 16:23

8 Answers 8

up vote 6 down vote accepted

If setX returns the bomb, yes.

public Bomb setX(Object x){
    this.x = x;
    return this;

Call this fluent interface. To achieve this fluent interface it is using a technique called method chaining.


share|improve this answer
See my answer for a tiny insignificant problem with java.beans.Introspector... –  alf Jan 7 '12 at 16:34

This is not a matter of invoking several methods at the same time, but of doing method chaining.

Typically, it is possible because these methods return this:

// class X
public X setX(int val)
    x = val;
    return this;

etc etc.

share|improve this answer
as above: please not that it won't be a JavaBean "setter" any more. –  alf Jan 7 '12 at 16:38

In order to make this syntax work, setX must return the object on which it operates. This is reasonably common. In C++ you return a reference to itself - see C++ streams for an example.

Bomb& Bomb::setX(X& newX) {
    x = newX;
    return *this;
share|improve this answer
Ahh Thanks for the c++ info –  Holly Jan 7 '12 at 16:16

As I understand you are talking about chaining invocation (when all void methods returns this). This feature is proposed to be in Java 7, but rejected I far as I know. So, there is no build-in mechanism for chaining invocation in java today. Look at Builder design pattern, it's very close but designed for readonly classes.

Also, you can always implement Fluent interface by yourself.

share|improve this answer

More ore less yes.

It will work if Bomb.setX() return its own instance.

class Bomb{


   Bomb setX(int value) {
      this.x = value;
      return this;


The complete topic is called fluent interface.

But unfortunaly the most Java Libs, and as far as I know, the complate java core, do not follow this idea. And the more worst thing is, that the Java-Bean Specification (the thing that define the relationship beween variable, getter and setter) is not based on this prinicip. So if you have an Framework that needs Java-Beans then it may or may not work with classes like that.

share|improve this answer

Well if the methods are correctly defined - then yes! Actually what you are looking for is a fluent interface. The main objective of a fluent interface is method chaining. For instance builders are oftend implemented in that way and you get:

new SomethingBuilder().withX(x).withY(y).build();

You just need to return (for instance) "this" in setX and setY.

share|improve this answer

Sure you can, but in order to do that every setter will need to return this, which is not too good for setters, as frameworks will not be able to find those any more. For example, the standard java.beans.Introspector ignores non-void setters:

public class Chain {
    private int i;

    public int getI() {
        return i;

    public Chain setI(int i) {
        this.i = i;
        return this;

    public static void main(String[] args) throws IntrospectionException {
        PropertyDescriptor[] propertyDescriptors = Introspector.getBeanInfo(Chain.class).getPropertyDescriptors();
        for (PropertyDescriptor propertyDescriptor : propertyDescriptors) {
            System.out.println("property = " + propertyDescriptor.getDisplayName());
            System.out.println("read = " + propertyDescriptor.getReadMethod());
            System.out.println("write = " + propertyDescriptor.getWriteMethod());


property = class
read = public final native java.lang.Class java.lang.Object.getClass()
write = null
property = i
read = public int org.acm.afilippov.Chain.getI()
write = null

Given that Apache BeanUtils uses it, chances are that many of Apache frameworks will decide that the property is readonly.

share|improve this answer
"frameworks will not be able to find those anymore", what do you mean –  Raynos Jan 7 '12 at 16:09
@Raynos well, setters in Java are used extensively by frameworks; and usually a setter is a method returning void. Returning anything else may well mean that frameworks will ignore the property. So a good practice would be, not call the methods to be chained setXxxx. –  alf Jan 7 '12 at 16:13
If the framework if done properly, then a proper getter/setter name and parameter list should be enough. Don't see why it should look at the return type while invoking it via reflection except for being 100% pure (i.e. setters MUST return void). –  Mateusz Dymczyk Jan 7 '12 at 16:15
@alf why do frameworks ignore properties that do not return void ? That just sounds like bad frameworks do bad stuff. –  Raynos Jan 7 '12 at 16:27
@Zenzen see the update for an actual case where frameworks fail to recognise the setter –  alf Jan 7 '12 at 16:31

You can, if setX and setY return the bomb object. This allows you to chain methods and this is referred to as the Fluent Interface. You can have a look at an example in Java here:


share|improve this answer

Your Answer


