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.
Recently after I updated my latest NetBeans binary, I got many of the following errors! Actually hundreds of them when opening a big project (P2). It should be fixed for M9; it's bad seeing so many warning during JavaONE demo (P1). WARNING [org.netbeans.api.java.source.JavaSource]: JavaSource.runUserActionTask called in AWT event thread by: java.awt.EventDispatchThread.pumpEvents(EventDisp atchThread.java:149)
Sorry, but the only bug in java/source I see regarding this is that the "by" is incorrect (it should show the caller of the JavaSource.runUserActionTask, not EDT.pumpEvents). This was partially fixed as of revision 1.40 of JavaSource, see below for more details. JavaSource.runUserActionTask should not be called from the AWT Event Dispatch Thread, because this method can block for arbitrary (long) time. Which leads in long-blocked AWT (the IDE is unresponsive during this time), which is a big problem IMO. We added this warning to find out who the callers from AWT are, so we can fix them. It will be necessary to fix the callers not to call JS.rUAT in the AWT thread. Sorry, but we are not going to remove the warning. For the JavaOne demo, we can suppress this warning by this command line option: -J-Dorg.netbeans.api.java.source.JavaSource.level=SEVERE Tomas, the warning works fine for me on JDK1.6, but does not on JDK1.5 (it prints: WARNING [org.netbeans.api.java.source.JavaSource]: JavaSource.runUserActionTask called in AWT event thread by: org.netbeans.api.java.source.JavaSource.runUserActionTask(JavaSource.java:415) which is not very helpful :-( ). We may need to go through the stack trace element by element, find JS.rUAT and show the element after it. Could you please take a look on this? Thanks.
Thanks Honza for evaluation. As I've written on nbdev the warning is intentional and we are not going to remove it. It is just a warning which is not shown in the final product. It's not an assertion. Indeed the warning helps to developer building on the top of java module to easily find out the "dangerous" code, it doesn't necessary say that the code is wrong but it signals that there may be a problem causing the UI to freeze. Seems that Thread.getStackFrames() depends on the VM, I fix it by logging stack frame above the JavaSource.run[UserAction|Modification]Task.