JDK-6451939 : JTextComponent.setEditable(false) forces change of component's background
  • Type: Bug
  • Component: client-libs
  • Sub-Component: javax.swing
  • Affected Version: 6
  • Priority: P2
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux
  • CPU: x86
  • Submitted: 2006-07-24
  • Updated: 2010-09-29
  • Resolved: 2006-08-24
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.
JDK 6
6 b96Fixed
Related Reports
Relates :  
JDK-4991597 - Win L&F: Non editable and disabled text components have incorrect background col
Relates :  
JDK-6420149 - REGRESSION: Non-editable textarea/textpane/editorpane should have white background
Relates :  
JDK-6463612 - 6451939 only fixed for Metal L&F
Description
Create a JTextArea and set the background color to some non-default value e.g. gray. Then set editable of this area to 'false'. It forces the change of background color back to default value.
This behavior introduces semantic in-compatibility between JDK1.4.2/JDK5 release and recent builds JDK6. This causes invalid state of many NetBeans dialogs and in products built of the top NetBeans as well.
See attached test which shows the problem, run the test /usr/local/share/java/jdk1.6.0/bin/java -ea -jar TestTextAreaBackground.jar.
Thanks
I don't agree that JTextComponent's can *correctly* change their background color when they are changed to non-editable in spite of previously set value. This change of JTextComponent has broken tons of dialogs in NetBeans product and even worse in all product built on the top of NetBeans platform.

The recently released tool Matisse generates code like 
JLabel label = new JLabel();
textComponent.setBackground(label.getBackground());
To fix all unexpectedly dialogs we have to fix form generation and then open and re-generate affected forms. Please, could you again think over about this implication and find any possible trade-off? Thanks
DELETED COMMENT
DELETED COMMENT
Comments
EVALUATION Turns out the fix I made for this only solved the problem for Metal. I'll revise the fix under 6463612.
24-08-2006
EVALUATION Just a note that this was introduced by 4991597.
02-08-2006
EVALUATION Although I strongly advise that new code not use this pattern, we don't want existing code to break. As such, for the time being, this will be fixed. If the component in question is a JTextArea/JTextPane/JEditorPane, we will check for UIResource, and additionally whether the color is one that the UI installed. We'll only change the color for this case. Note that this will be done only on editable/enabled state changes. Reinstalling the UI will continue to replace the color as it always did.
01-08-2006
EVALUATION Submitter writes: --- I don't agree that JTextComponent's can *correctly* change their background color when they are changed to non-editable in spite of previously set value. This change of JTextComponent has broken tons of dialogs in NetBeans product and even worse in all product built on the top of NetBeans platform. The recently released tool Matisse generates code like JLabel label = new JLabel(); textComponent.setBackground(label.getBackground()); To fix all unexpectedly dialogs we have to fix form generation and then open and re-generate affected forms. Please, could you again think over about this implication and find any possible trade-off? Thanks --- I've e-mailed the submitter with the following response: --- NetBeans/Matisse is *clearly* doing something wrong here and we certainly do not want it to be emitting the code that you've demonstrated. We don't want developers copying this pattern. UIResource is the only way we have to tag things so that we know they're okay to change. Consider that the pattern you've demonstrated also breaks down when the look and feel changes. That is, Look and Feels also replace colors when tagged with UIResource. --- As such, closing again as will not fix. It is strongly advised that NetBeans be fixed to not emit this pattern.
26-07-2006
EVALUATION JTextComponent's *correctly* change their background color when they are changed to non-editable. However, they ONLY do so if the current background color is a UIResource. UIResource indicates that the color was installed by the UI and can freely be replaced by the UI at any time. UIResource has ALWAYS meant this. The problem here is that the client code is doing something like: JLabel label = new JLabel(); textComponent.setBackground(label.getBackground()); Since JLabel's background (installed by the UI) is a UIResource, the text component's background continues to be a UIResource. As such, it can freely be replaced at any time by the UI code. If the submitter wishes to lock in the color, they can set it to a new color based on the color of the label.
24-07-2006