Thread: JButton constructor problem

Originally Posted by Norm

Why are you adding the {this(null,null); to the above description of the syntax for calling a constructor?
What are you referring to here? Where have you seen source code like this?

I believe he's trying to talk about the source of JButton. He's using some wonky syntax, but what he has matches the source of JButton. I think he's asking about how the constructors are chained together.

The gist: this() is a way of calling another constructor. It will simply call the constructor that matches the arguments given. So this is JButton's source:

    public JButton() {
        this(null, null);
    }
 
    public JButton(Icon icon) {
        this(null, icon);
    }
 
    public JButton(String text) {
        this(text, null);
    }
 
    public JButton(Action a) {
        this();
	setAction(a);
    }
 
    public JButton(String text, Icon icon) {
        // Create the model
        setModel(new DefaultButtonModel());
 
        // initialize
        init(text, icon);
    }

Basically, the first three constructors (the no-args and the String or Icon constructors) all simply call the two-argument constructor with a dummy value (null) for the missing piece. The constructor that takes an Action calls the first, no-arg constructor (which will then call the two-args constructor) and sets its Action.

The init(text, icon) function is actually in AbstractButton, and it looks like this:

protected void init(String text, Icon icon) {
        if(text != null) {
            setText(text);
        }
 
        if(icon != null) {
            setIcon(icon);
        }
 
        // Set the UI
        updateUI();
 
        setAlignmentX(LEFT_ALIGNMENT);
        setAlignmentY(CENTER_ALIGNMENT);
    }

So, the init() function checks to make sure each argument isn't a dummy value, and calls the appropriate setter for that attribute.

Does that make any sense?

Originally Posted by Norm

Good observation. It can be hard figuring out what the h... an OP is asking.

True that. I could also be completely wrong and just talking gibberish!

So did I answer your original question?

Those are indeed javadoc comments, and they are converted into the API: Java Platform SE 6

Originally Posted by Nieuwenhuizen-jk

The first 4 constructors have no body.

What do you mean by this? Yes they absolutely do.

Originally Posted by Nieuwenhuizen-jk

if JButton itself had a data member of class String, named 'text' I had expected a body like

this.text = text;

and similarly with icon. But there are no such fields, there is even no body of the constructor.

I already explained this to you. They are passed into the init() method of AbstractButton. I even posted the body of that method for you to examine.

Originally Posted by Nieuwenhuizen-jk

The parent, the superclass, is

AbstractButton extends JComponent

but these have no members of those names,
and if they had I expected a statement of the form `super.xxx`.

Like I said, they are passed as parameters to the init() function, which passes them to the setText() and setIcon() methods.

Originally Posted by Nieuwenhuizen-jk

Therefore the question is simple: How does the compiler handle these bodyless constructors?

Again, what do you mean by "bodyless constructors"? The constructors do indeed have bodies. You actually posted the bodies yourself!

Originally Posted by Nieuwenhuizen-jk

There is no data member of name 'text', nor of 'Icon' in AbstractButton or Jcomponent, nor in the implementations

False. From AbstractButton:

    private String     text                    = ""; (line 144)
    private Icon       defaultIcon             = null; (line 150)

Originally Posted by Nieuwenhuizen-jk

I made an answer yesterday, as far as I know posted it, at 11 sep but do not see it back.

Are you sure it's not on the first page?

Originally Posted by Nieuwenhuizen-jk

But I looked back and think I understand most of KevinWorkman's reaction of 2011-09-08T13:05:

The compiler does not "understand" how to handle a constructor without data


public JButton() {
this(null, null);
}

and instead go going back where it came from goes to the second, third, fourth

public JButton(Icon icon) {
this(null, icon);
}

public JButton(String text) {
this(text, null);
}

public JButton(Action a) { // skipped, different parameter class
this();
setAction(a);
}


and eventually arrives at

public JButton(String text, Icon icon) {
// Create the model
setModel(new DefaultButtonModel());

// initialize
init(text, icon);
}

No. It doesn't go from one to the other to eventually arrive. This line from the no-args constructor:

this(null, null);

Directly calls the two-args constructor.

Originally Posted by Nieuwenhuizen-jk

finds SetModel in Abstract... line 1718, I don't know where it finds DefaultButtonModel ( not in Abstract..., not in JComponent} although Abstract... uses it in line 1297 and finds init in Abstract...line 2139

Huh? What do you mean "where it finds"? What do you mean by any of this, actually?

Originally Posted by Nieuwenhuizen-jk

But I do not see why this is better than

public JButton(String text, Icon icon) {

if(text != null) { // copied from init(String
setText(text);
}

if(icon != null) {
setIcon(icon);
}

// Set the UI
updateUI();

setAlignmentX(LEFT_ALIGNMENT);
setAlignmentY(CENTER_ALIGNMENT);
}
}

It's simply a short cut. People don't love passing in null arguments. That's it. No magic.

Originally Posted by Nieuwenhuizen-jk

Do I ask to much if I say : "Can you please explain to me why this is not? ( I have an habit in trying to understand why people do better jobs than I do )"

What? Why what is not?

Originally Posted by Nieuwenhuizen-jk

And I am always open for good advices to solve the "TripleButton" problem, sketched before?

What TripleButton problem?

You seem to have a pretty basic misunderstanding of how Java works. Before you dive into Swing source code, I highly recommend starting over at the beginner tutorials.