Colors and the Color Class in Java

Most colors you have used so far in Java are solid. When you draw with them, whatever you paint replaces what was underneath. Sometimes you want the opposite: a shape that lets the shapes beneath it show through. Java handles this with colors that carry an alpha component. This article starts from a small program that builds transparent colors and asks you to reason about what each color will look like, then explains the rules that make those predictions work.

Colors with alpha components were introduced in Java along with Graphics2D, but they can also be used with ordinary Graphics objects. The alpha component is the part of a color that controls its opacity. Opacity describes how much of the drawing underneath a color shows through it. A higher alpha value makes the color more opaque, so less of what lies beneath is visible. A lower alpha value makes it more transparent, so more of the underlying drawing shows through.

Read the top row of the figure first. A fully opaque red overlay covers the blue background in the region it occupies, so the blue is replaced and only red is visible there. Now read the bottom row. The same red shape is semi-transparent, so the blue beneath it still reaches your eye and the visible result is a mixture of the two. Nothing about the shape changed except its alpha value. That single number is what separates a solid replacement from a see-through overlay.

Once a transparent color exists, you use it exactly the way you use any other color. The source describes this with a Color named c and a graphics context named g. Calling g.setColor(c) sets the color for subsequent drawing, and this is the same mechanism used for opaque colors. The color is a piece of state held by the graphics context. It stays in effect until another setColor call replaces it.

Follow the figure from top to bottom. The Color c is created once and then passed to setColor, which makes it the active color. The fillRect call that comes next draws with c, so the transparency of c applies to that shape. The active color does not switch back on its own. It changes only when another setColor call runs, which is why the second fillRect in the figure uses a different color. When you trace a program, track the active color as a value that moves forward line by line, not as something tied to the variable name c.

The Color class offers two constructors that accept an alpha component. Both take four parameters: three color channels and one alpha value. The forms differ in the kind of number they expect. The first uses integers, and the second uses floating-point numbers. Read a constructor call from left to right. The first three arguments set the red, green, and blue channels, and the last argument sets the alpha component. The alpha argument is the last position in both forms, and its range matches the range of the other three arguments for that constructor.

The two columns in the figure describe the same range of opacity written in two different number styles. The integer form runs from 0 to 255, and the float form runs from 0.0 to 1.0. The endpoints match: the lowest value on each scale is the most transparent setting, and the highest value is fully opaque. The middle values also correspond. The integer alpha of 200 is the first color in the source, described as slightly transparent. The float alpha of 0.5 is the second color, described as 50 percent opaque. Those two numbers are written differently, but each one is read against its own scale.

The float form lets you think in percentages. A value of 0.5 is a half, which is exactly the 50 percent figure the source gives. That is the main reason to prefer the float form when your reasoning is already about proportions. The integer form fits better when you are working with values that are already in the 0 to 255 range.

The three-argument constructor creates a color with only red, green, and blue values, so no alpha value appears in the call. Before reading the answer, commit to a prediction about the opacity that Java gives such a color.

The reasoning is simple once you know the rule. A three-argument color has no transparency set by the program, so it is fully opaque. To make a color transparent, you must use one of the four-argument constructors and choose an alpha value that is less than fully opaque. The three-argument call is the signal that the color should be solid.

When a transparent-color program produces a result you did not expect, do not start by asking whether the whole program is wrong. Move line by line and stop at the first line where the stored value differs from your prediction. That line is the failure location. For each line, ask two questions: which value is being stored, and does that value fall inside the range the constructor requires? Most surprising results trace back to one of those two questions, and the cause is almost always in the arguments on that line or in the choice of constructor.