JDK-6434931 : Usage of background colors and setOpaque(true) is confusing and inconsistent.
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version:
    6,6u23,7u2,8,9,10,11,12,13,14,15,16,17 6,6u23,7u2,8,9,10,11,12,13,14,15,16,17
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • OS: windows
  • CPU: generic,x86
  • Submitted: 2006-06-06
  • Updated: 2021-07-01
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Related Reports
Duplicate :  
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Relates :  
The usage of setOpaque is essentially an implementation detail to speed up drawing but because certain standard components change their drawing behavior when setOpaque is set to false this has created confusion about setOpaque really means. Adding to this confusion is the advent of L&Fs which use OS derived skins. It is unclear how a skinned component should be drawn when a developer sets the background color to something other than the default. Should the color be ignored, should it replace the skin, or should it augment the skin somehow. Currently this behavior is inconsistent and depends on the component and the current look and feel and running platform. To further complicate matters, JButton has extra properties to control when the content should be painted, but only JButton has these properties.  

Once a compatibility API is in place we should define and document exactly how all of these properties fit together, especially in the light of forward looking native look and feels for Mac OS X and Vista.

Once this issue is settled several related bugs regarding buttons and toolbars will have solutions. (see attached bug ids).

There is a same issue on jdk7u72b09(64bit) with win7-sp1-x64 platform. Swing_JProgressbar/Manual/ProgressBarBackground

EVALUATION The fix for 6418117 figures to this bug as well. Right now it has a hard coded test for JToolBars with XP skins that use borderfill. In this case it will not paint the skin, allowing the normal (non-skin) background color painting to come through. We should decide if this is the correct behavior for all components or not. Doing so would allow any component to override it's background color, but it would only work if the skin used borderfill, which would not be the case on all visual styles.