Working with JCheckBox and JRadioButton Components

Imagine a Swing window with a row of checkboxes, where one of them looks wrong. It is still a box with a check mark, but the picture does not match the design you wanted. Before you can fix that, you need to know what the box on the screen actually is and which part of your program controls it.

This article starts from that practical question. You will first think about what a checkbox displays in each of its states, then trace the mechanism that produces the picture, and finally learn how to find the exact step where a customized button stops showing what you intended.

A JCheckBox draws its box from a pair of Icons: one for the unselected state and one for the selected state. The component does not decide how to render a check mark each time it is painted. It looks at whether it is selected and displays the icon that belongs to that state.

Because the choice depends only on the selection state, customizing the appearance means replacing one or both of those icons. The source describes this directly: you can change the look of the check box by substituting different icons for the standard ones.

Read the diagram as a two-state cycle. Each click moves the checkbox from one state to the other, and the icon drawn follows the state. The box is never drawn from scratch as a check mark; it is always one of the two icons assigned to it.

The two icons play different roles, and the source names the methods that control each one. The icon for the unselected state is the main icon of the JCheckBox. You can supply it when the component is constructed, or you can replace it later with setIcon().

The icon for the selected state is changed with setSelectedIcon(). Both methods belong to the JCheckBox object, so you call them on the particular checkbox you want to customize. Changing one checkbox does not require changing the others.

A simple way to hold this mapping in mind is to ask two separate questions. Which icon does this state use? If the answer is unselected, the constructor argument or setIcon() set it. If the answer is selected, setSelectedIcon() set it.

The following scenario is an original illustration built from the rules above. Suppose a developer wants a checkbox that shows an empty circle when unselected and a check mark when selected. The developer calls setIcon() with the check mark image and setSelectedIcon() with the circle image, so the two assignments are swapped.

The trace shows that every state is wrong, not only the selected one. The departure begins at the first step, because the unselected icon was assigned incorrectly. Tracing from the start, one step at a time, is what makes this visible. Checking only the final look of a clicked checkbox would suggest that the click logic is at fault, which is the wrong place to look.

The same pattern is not limited to checkboxes. The source states that all of this applies equally to JRadioButton, JCheckBoxMenuItem, and JRadioButtonMenuItem. A radio button therefore has an unselected icon and a selected icon, and you customize them with the same two methods: setIcon() for the unselected appearance and setSelectedIcon() for the selected appearance.

The source names the radio button as the one place where its concrete example adds a further detail. Because a radio button usually belongs to a group, its customization happens during setup alongside its grouping, as the next example shows.

The source points to ToolBarDemo.java as a concrete case. That program creates a set of radio buttons that use custom icons. It builds each button in a helper method whose documentation says it creates a JRadioButton and adds it to a specified button group.

The excerpt shows that the button group is part of the construction. Customizing a radio button therefore happens while the button is being set up, alongside its grouping. When you trace a problem in such a button, start at this setup code, because that is where its icon calls and its group membership are established together.