The short answer to your question is that “opaque” is defined in English as completely non-transparent. Therefore an opaque component is one which paints its entire rectangle, and every pixel is not at all translucent to any degree.
However, the Swing component opacity API is one of those mis-designed and therefore often mis-used APIs.
What’s important to understand is that isOpaque is a contract between the Swing system and a particular component. If it returns true, the component guarantees to non-translucently paint every pixel of its rectangular area. This API should have been abstract to force all component writers to consider it. The isOpaque API is used by Swing’s painting system to determine whether the area covered by a given component must be painted for components which overlap it and which are behind it, including the component’s container and ancestors. If a component returns true to this API, the Swing system may optimize painting to not paint anything in that area until invoking the specific component’s paint method.
Because of contractual implication of isOpaque, the API setOpaque should not exist, since it is actually incorrect for anything external to call setOpaque since, in turn, the external thing can’t know whether the component in question will (or even can) honor it. Instead, isOpaque should have been overridden by each concrete component to return whether it actually is, in fact, opaque given its current properties.
Because the setOpaque API does exist, many components have mis-implemented it (quite understandably) to drive whether or not they will paint their “background” (for example JLabel and JPanel filling with their background color). The effect of this is to create an impression with users of the API to think that setOpaque drives whether or not that background should paint, but it doesn’t.
Furthermore, if, say, you wish to paint a JLabel with a translucent background you need to set a background color with an alpha value, and do setOpaque(true), but it’s not actually opaque – it’s translucent; the components behind it still need to paint in order for the component to render properly.
This problem was exposed in a significant way with the Java 6’s new Nimbus Look & Feel. There are numerous bug reports regarding transparent components filed against Nimbus (see stack overflow question Java Nimbus LAF with transparent text fields). The response of the Nimbus development team is this:
This is a problem [in] the orginal design of Swing and how it has been confusing for years. The issue is setOpaque(false) has had a side effect in [existing] LAFs which is that of hiding the background which is not really what it is [meant] for. It is [meant] to say that the component may have transparent parts and [Swing] should paint the parent component behind it.
So, in summary, you should not use setOpaque. If you do use it, bear in mind that the combination of some Look & Feels and some components may do “surprising” things. And, in the end, there is actually no right answer.