This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
After installing the CheckThreadViolationRepaintManager from the SwingHelper project in our application which is based on the Netbeans platform I found a lot of EDT violations in netbeans code (please see attachment).
Created attachment 57368 [details] Callstacks of EDT violations
Created attachment 57369 [details] Module suite project showing the issue.
This is duplicate of 126146. And as I wrote in 126146, I think CheckThreadViolationRepaintManager is not correctly written and these EDT violations exceptions from the rule and should be considered as OK. *** This issue has been marked as a duplicate of 126146 ***
I don't agree with dsimonek. Each (new) swing tutorial says that you have to use something like this to create the GUI: import javax.swing.*; public class HelloWorldSwing { /** * Create the GUI and show it. For thread safety, * this method should be invoked from the * event-dispatching thread. */ private static void createAndShowGUI() { //Create and set up the window. JFrame frame = new JFrame("HelloWorldSwing"); frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); //Add the ubiquitous "Hello World" label. JLabel label = new JLabel("Hello World"); frame.getContentPane().add(label); //Display the window. frame.pack(); frame.setVisible(true); } public static void main(String[] args) { //Schedule a job for the event-dispatching thread: //creating and showing this application's GUI. javax.swing.SwingUtilities.invokeLater(new Runnable() { public void run() { createAndShowGUI(); } }); } } One reason for this EDT rule is, that for example adding components to a container will fire the methods from the ContainerListener interface. If adding components is done from a non-EDT the listeners will be informed in this other thread as well. Changing a property in the wrong thread will call the PopertyChange-listeners in the wrong thread. All this breaks the contract, that listeners are allways called on the EDT. Another reason is that - according to the java memory model (*) - the change of a value (for example a boolean) in one thread may not be "seen" from another thread. Please do reconsider your decision not to fix this bug even if you don't see a bad behavior in the moment. The new multi-CPU/multi-core systems don't forgive any carelessness. Swing threading issues can be very subtle and very hard to find. Best regards, Martin (*) The java memory model does not require that a variable has to be written/read to/from the main memory each time it is used. Different threads may therefore have different copies)
Some further tests revealed that netbeans not only violates the EDT rule in the startup phase but also during runtime for example when opening the Options->Font&Colors dialog as shown below. It is definitely forbidden to call JComboBox.setEnabled() or JComboBox.setSelectedItem() from a non-EDT. As I said in my former posting, property change events are fired and the listeners are called in the wrong thread. Best regards, Martin EDT violation detected javax.swing.plaf.basic.BasicComboPopup$1 [ComboBox.list,0,0,0x0,invalid,alignmentX=0.0,alignmentY=0.0,border=,flags=50331944,maximumSize=,minimumSize=,preferredSize=,fixedCellHeight=-1,fixedCellWidth=-1,horizontalScrollIncrement=-1,selectionBackground=javax.swing.plaf.ColorUIResource[r=163,g=184,b=204],selectionForeground=sun.swing.PrintColorUIResource[r=51,g=51,b=51],visibleRowCount=8,layoutOrientation=0] at java.lang.Thread.getStackTrace(Unknown Source) at org.jdesktop.swinghelper.debug.CheckThreadViolationRepaintManager.checkThreadViolations(CheckThreadViolationRepaintManager.java:74) at org.jdesktop.swinghelper.debug.CheckThreadViolationRepaintManager.addDirtyRegion(CheckThreadViolationRepaintManager.java:65) at javax.swing.JComponent.repaint(Unknown Source) at java.awt.Component.repaint(Unknown Source) at javax.swing.plaf.basic.BasicListUI.redrawList(Unknown Source) at javax.swing.plaf.basic.BasicListUI.access$900(Unknown Source) at javax.swing.plaf.basic.BasicListUI$Handler.contentsChanged(Unknown Source) at javax.swing.AbstractListModel.fireContentsChanged(Unknown Source) at javax.swing.DefaultComboBoxModel.setSelectedItem(Unknown Source) at javax.swing.JComboBox.setSelectedItem(Unknown Source) at org.netbeans.modules.options.colors.ColorComboBox.setColor(ColorComboBox.java:110) at org.netbeans.modules.options.colors.SyntaxColoringPanel.refreshUI(SyntaxColoringPanel.java:704) at org.netbeans.modules.options.colors.SyntaxColoringPanel.access$200(SyntaxColoringPanel.java:91) at org.netbeans.modules.options.colors.SyntaxColoringPanel$2.run(SyntaxColoringPanel.java:178) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986) EDT violation detected javax.swing.JComboBox[,790,176,512x18,disabled,layout=javax.swing.plaf.metal.MetalComboBoxUI$MetalComboBoxLayoutManager,alignmentX=0.0,alignmentY=0.0,border=,flags=20971848,maximumSize=,minimumSize=,preferredSize=,isEditable=true,lightWeightPopupEnabled=false,maximumRowCount=8,selectedItemReminder=org.netbeans.modules.options.colors.ColorValue@17f13c5] at java.lang.Thread.getStackTrace(Unknown Source) at org.jdesktop.swinghelper.debug.CheckThreadViolationRepaintManager.checkThreadViolations(CheckThreadViolationRepaintManager.java:74) at org.jdesktop.swinghelper.debug.CheckThreadViolationRepaintManager.addDirtyRegion(CheckThreadViolationRepaintManager.java:65) at javax.swing.JComponent.repaint(Unknown Source) at java.awt.Component.repaint(Unknown Source) at javax.swing.plaf.basic.BasicComboBoxUI$Handler.propertyChange(Unknown Source) at javax.swing.plaf.basic.BasicComboBoxUI$PropertyChangeHandler.propertyChange(Unknown Source) at javax.swing.plaf.metal.MetalComboBoxUI$MetalPropertyChangeListener.propertyChange(Unknown Source) at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source) at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source) at java.beans.PropertyChangeSupport.firePropertyChange(Unknown Source) at java.awt.Component.firePropertyChange(Unknown Source) at javax.swing.JComponent.firePropertyChange(Unknown Source) at javax.swing.JComboBox.setEnabled(Unknown Source) at org.netbeans.modules.options.colors.SyntaxColoringPanel.refreshUI(SyntaxColoringPanel.java:734) at org.netbeans.modules.options.colors.SyntaxColoringPanel.access$200(SyntaxColoringPanel.java:91) at org.netbeans.modules.options.colors.SyntaxColoringPanel$2.run(SyntaxColoringPanel.java:178) at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:561) at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:986)
Please have a look at: http://www.javaworld.com/javaworld/jw-08-2007/jw-08-swingthreading.html?page=5 they have nice examples showing why it is wrong to create a swing GUI outside the EDT.
Quote from NetBeans book 'Rich Client Programming', page 120: "... we are trusting that Swing and NetBeans will play by the rules and never call methods on our model from some random thread. As long as that holds true, we know that at the time we are copying data ...".
To hmichel, as you can see from my posting on Fri Feb 29, the swing EDT rule is clearly violated. Swing demands that components may only be manipulated from the EDT and on the other hand swing will assure that listeners will always be notified from the EDT. Both rules are violated as you can see from the stack trace I sent on Feb 29. From RequestProcessor$Processor.run() (which is not the EDT) the enabled property of a JComboBox is set, which leads to JComponent.firePropertyChange(), which in turn calls the listeners outside the EDT. According to the java memory model unsynchronized modification of a boolean variable may not be seen from another thread. That means the EDT may not be aware of the change. In the moment you may feel safe because most users only have single CPU computers on which these problems may not happen. But as I know from own experience on multicore systems you will most likely run into problems. Please have a look at: http://www.javaworld.com/javaworld/jw-08-2007/jw-08-swingthreading.html?page=5 they have really nice examples. Best regards, Martin Goettlicher
According to a statement from Josh Marinacci (former member of the Swing Team, and now one of the most prominent JavaFX developers) cited in http://eppleton.sharedhost.de/blog/?p=826 component creation off EDT is a bug so I reopen this bug. Best regards, Martin Goettlicher
OK, I agree that this is a bug now, I'm glad that Swing team made it clear finally. However, we agreed *not* to work on this unless it really breaks some functionality. Simply not enough resources here and we have to pay attention to functionality bugs first. Therefore I'm closing with LATER. If anyone from community is really interested in it, feel free to submit patches, for example using NetDev process: http://wiki.netbeans.org/NetDEV#ref-NetDEV-1
NetBeans.org Migration: changing resolution from LATER to WONTFIX
I don't think this issue should be closed. Threading bugs are notoriously hard to track down. If you want to fix this later, fine, but it should get fixed in the end.
(In reply to comment #12) > I don't think this issue should be closed. Threading bugs are notoriously hard > to track down. If you want to fix this later, fine, but it should get fixed in > the end. please file separate issues if there are specific problems caused by swing components being created or manipulated outside EDT we don't have resources to check and rewrite every piece of GUI code