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.
Build: NetBeans IDE 6.7.1 (Build 200907230233) VM: Java HotSpot(TM) 64-Bit Server VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Linux, 2.6.18-128.7.1.el5, amd64 User Comments: malm: Starting NetBeans GUEST: Started Netbeans v6.7 GUEST: starting ide GUEST: restart netbeans after crash Stacktrace: java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Hashtable.java:1031) at com.sun.java.swing.plaf.nimbus.NimbusStyle.compileDefaults(NimbusStyle.java:378) at com.sun.java.swing.plaf.nimbus.NimbusStyle.validate(NimbusStyle.java:297) at com.sun.java.swing.plaf.nimbus.NimbusStyle.getValues(NimbusStyle.java:927) at com.sun.java.swing.plaf.nimbus.NimbusStyle.getInsets(NimbusStyle.java:605) at javax.swing.plaf.synth.SynthStyle.installDefaults(SynthStyle.java:896)
Created attachment 89402 [details] stacktrace
This issue already has 6 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=152926
This issue already has 9 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=152926
Build: NetBeans IDE 6.8 Beta (Build 200910212001) VM: Java HotSpot(TM) 64-Bit Server VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Linux, 2.6.30.8-64.fc11.x86_64, amd64 User Comments: opening the ide Stacktrace: java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Hashtable.java:1031) at com.sun.java.swing.plaf.nimbus.NimbusStyle.compileDefaults(NimbusStyle.java:378) at com.sun.java.swing.plaf.nimbus.NimbusStyle.validate(NimbusStyle.java:297) at com.sun.java.swing.plaf.nimbus.NimbusStyle.getValues(NimbusStyle.java:927) at com.sun.java.swing.plaf.nimbus.NimbusStyle.getInsets(NimbusStyle.java:605) at javax.swing.plaf.synth.SynthStyle.installDefaults(SynthStyle.java:896)
Created attachment 90262 [details] stacktrace
This issue already has 10 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=152926
Build: NetBeans IDE 6.8 Beta (Build 200910212001) VM: Java HotSpot(TM) 64-Bit Server VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Linux, 2.6.30.8-64.fc11.x86_64, amd64 User Comments: opening ide Stacktrace: java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Hashtable.java:1031) at com.sun.java.swing.plaf.nimbus.NimbusStyle.compileDefaults(NimbusStyle.java:378) at com.sun.java.swing.plaf.nimbus.NimbusStyle.validate(NimbusStyle.java:297) at com.sun.java.swing.plaf.nimbus.NimbusStyle.getValues(NimbusStyle.java:927) at com.sun.java.swing.plaf.nimbus.NimbusStyle.getInsets(NimbusStyle.java:605) at javax.swing.plaf.synth.SynthStyle.installDefaults(SynthStyle.java:896)
Created attachment 90263 [details] stacktrace
This issue already has 11 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=152926
This issue already has 12 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=152926
Build: NetBeans IDE Dev (Build 200910310201) VM: Java HotSpot(TM) 64-Bit Server VM, 14.2-b01, Java(TM) SE Runtime Environment, 1.6.0_16-b01 OS: Linux, 2.6.30.8-64.fc11.x86_64, amd64 User Comments: opening IDE. Stacktrace: java.util.ConcurrentModificationException at java.util.Hashtable$Enumerator.next(Hashtable.java:1031) at com.sun.java.swing.plaf.nimbus.NimbusStyle.compileDefaults(NimbusStyle.java:378) at com.sun.java.swing.plaf.nimbus.NimbusStyle.validate(NimbusStyle.java:297) at com.sun.java.swing.plaf.nimbus.NimbusStyle.getValues(NimbusStyle.java:927) at com.sun.java.swing.plaf.nimbus.NimbusStyle.getInsets(NimbusStyle.java:605) at javax.swing.plaf.synth.SynthStyle.installDefaults(SynthStyle.java:896)
Created attachment 90530 [details] stacktrace
This issue already has 14 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=152926
reported 32 times ( 16 for NB 6.8 Beta & 2 for RC1 ) so far .... needs to be at least evaluated whether we can do anything to avoid such exception
it's Nimbus l&f specific - UI elements are being instantiated outside AWT and Nimbus doesn't like that at all... there's no simple fix for this issue short of rewriting most of our startup code (creating menu bars, toolbars and action pool)
Stando, thanks for the evaluation.
This bug already has 50 duplicates see http://statistics.netbeans.org/exceptions/detail.do?id=152926
not P1 as workaround exists (just use metal l&f instead of nimbus)
waiver request justification: this bug occurs (intermittently) only when running under nimbus l&f due to lack of thread synchronization in nimbus l&f implementation. an easy fix is switching to other l&f - either the sytem l&f or to metal l&f. to fix this bug we'd have rewrite the initialization of actions and main menu bars to move component creation to EDT. possibly also all other cases where swing components are created and initialized in a background thread may cause this issue.
(In reply to comment #19) > we'd have rewrite the initialization of actions and main menu > bars to move component creation to EDT. possibly also all other cases where > swing components are created and initialized in a background thread We definitely want to do this, but I agree that it is too much work and too risky for 6.9.
You might want to add some logging to Nimbus and find out what the actual culprit is which changes this collection while the EDT is iterating it. There might be a very simple workaround to avoid touching that particular UI class or cause it to be iterated safely - without any dramatic change to threading behavior.
there are no exception reports from nb 7.0 nor from recent dev builds. closing.
*** Bug 222219 has been marked as a duplicate of this bug. ***
This problem continues to haunt us (and our userbase) on our platform application based on recent builds (7.1-7.3). We have 3000+ installed clients based on the nb platform (client-server accounting software) and we are getting reports of this problem every now and then (on win/osx/linux) and we can't be the only ones.
(In reply to comment #24) > This problem continues to haunt us (and our userbase) on our platform > application based on recent builds (7.1-7.3). > > We have 3000+ installed clients based on the nb platform (client-server > accounting software) and we are getting reports of this problem every now and > then (on win/osx/linux) and we can't be the only ones. Then attach a fresh IDE log with stack trace and reopen. But there isn't much we can do about it, Nimbus l&f isn't thread safe.
(In reply to comment #25) > Then attach a fresh IDE log with stack trace and reopen. But there isn't much > we can do about it, Nimbus l&f isn't thread safe. I don't agree with you, you actually have a lot of work to do as stated by comment #20. It is a NB seriously issue because it do the things in the wrong way. Nimbus is not thread safe because it is not supposed to be, NB that is supposed to run all Swing related stuff at EDT thread. The way Swing works is a known way that UI frameworks work, using a single thread to do UI related stuff and do not need to deal with threads issues. @HenryA please attach some updated log files.
(In reply to comment #26) > (In reply to comment #25) > > Then attach a fresh IDE log with stack trace and reopen. But there isn't much > > we can do about it, Nimbus l&f isn't thread safe. > I don't agree with you, you actually have a lot of work to do as stated by > comment #20. It is a NB seriously issue because it do the things in the wrong > way. Nimbus is not thread safe because it is not supposed to be, NB that is > supposed to run all Swing related stuff at EDT thread. The way Swing works is a > known way that UI frameworks work, using a single thread to do UI related stuff > and do not need to deal with threads issues. Please show me Javadoc reference where it says that the creation of UI components is allowed in EDT only.
I have no idea if it is stated in any Javadoc, but we have this stated at Java Tutorial [1] (where I learnt it in the past) and I have read it in Java Concurrency in Practice from Brian Goetz, where he quotes more frameworks that work in the same way. The problem is that Swing components are not supposed or obligated to be thread-safe, the API does not demands it so we just can't rely on that. I haven't debugged the issue as well so I am not saying the bug is not in the Nimbus side, but I am sure that if the problem is Nimbus thread-safety, it is not supposed to be in that way. [1] http://docs.oracle.com/javase/tutorial/uiswing/concurrency/dispatch.html
That reference doesn't say anything about creating complex UIs off the EDT for performance reasons and then manipulating them in EDT thread - which is IMHO a common practice, look at e.g. SwingSet demo app. Nimbus look and feel is the only implementation that has problem with this approach. And that's why we print a warning into IDE log when Nimbus l&f is used in the IDE.
Creating UI components outside the EDT is a very old issue in Netbeans. In 2008 I reported the bug 128582. In the discussion of this bug I cited an answer from Josh Marinacci a former member of the Swing team (http://eppleton.de/blog/?p=826). In his statement Josh answered the question "Is component creation off EDT a bug?" with "yes, it’s a bug". David Simonek from the Netbeans team replied to that statement at 2009-07-28 11:00:26 "OK, I agree that this is a bug now, I'm glad that Swing team made it clear finally." The reason why it is a bug is easy to understand. Setting properties in a constructor may trigger property change events. If the constructor is called outside the EDT, the listeners will also be called outside the EDT. If non thread safe data structures are used in the constructor this usage will also collide with using this structures from the EDT. Best regards, Martin
As I said, I am not saying it is not a Nimbus issue :-) I know it is buggy, I have issues with Nimbus in the past too. Thanks a lot Stanislav for your comments :)
(In reply to comment #30) > Creating UI components outside the EDT is a very old issue in Netbeans. In 2008 > I reported the bug 128582. In the discussion of this bug I cited an answer from > Josh Marinacci a former member of the Swing team > (http://eppleton.de/blog/?p=826). In his statement Josh answered the question > "Is component creation off EDT a bug?" with "yes, it’s a bug". David Simonek > from the Netbeans team replied to that statement at 2009-07-28 11:00:26 "OK, I > agree that this is a bug now, I'm glad that Swing team made it clear finally." OK, point taken. I'll bring it up to our performance team but I don't see any major rewrite of NetBeans in the near future. In the mean time just use other look and feel than Nimbus.
Interesting: since some resent platform change, the actual stack trace has changed to ones like the one I attach. I asume that this is just another representation of the same basic problem, but I'm happy to file it as a new bug if you think I should?
Created attachment 135794 [details] NullPointerException stacktrace
(In reply to comment #34) > Created attachment 135794 [details] > NullPointerException stacktrace This particular stack trace is most likely a duplicate of #213901
Created attachment 137928 [details] ConcurrentModificationException in 7.2 platform app