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 creating a simple Visual Web project (P2). It should be fixed for M9; it's bad seeing so many warning during JavaONE demo (P1). If that can't make it, we may need to add the following command line option for JavaONE demo setting: -J-Dorg.netbeans.api.java.source.JavaSource.level=SEVERE By using JDK 6, the warning shows: WARNING [org.netbeans.api.java.source.JavaSource]: JavaSource.runUserActionTask called in AWT event thread by: org.netbeans.modules.visualweb.insync.java.ReadTaskWrapper.execute(ReadTaskWrapper.java:58) WARNING [org.netbeans.api.java.source.JavaSource]: JavaSource.runModificationTask called in AWT event thread by: org.netbeans.modules.visualweb.insync.java.WriteTaskWrapper.execute(WriteTaskWrapper.java:70) By using JDK 5, the warning shows: WARNING [org.netbeans.api.java.source.JavaSource]: JavaSource.runUserActionTask called in AWT event thread by: java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:149)
I am not sure if this is a P1 in terms of the fact that the warnings are shown. In fact this was not specified in the original Retouche APIs that JavaSource.runUserActionTask() cannot be called on AWT thread, even though I understand the spirit behind it. This is a general principle issue. Any long running work cannot be done on AWT thread as that blocks the UI. The JavaSource.runUserActionTask() has a potential to be a long running task. The real issue is that from the Creator days the Insync work is done on the AWT thread. To move it to a differrent thread and achieve the synchronization, coordinationin and notification with the clients will require significant work.
We know that the decision to show these warnings was discussed and made recently but I was not aware that every place that warning is shown is fixed right away. Another issue is that the logging of these warnings themselves is a lot of I/O and may be slowing down the IDE.
I agree Warning mesg is OK. But there are hundreds of them for just a small project, then it's not OK.
I think the number of messages simply proportional to how many times Insync has to access the Retouche functionality. The real primary issue is not the number of messages. It is that the work is being done on the AWT thread.
According to comment for 101626, this warning will not be part of final product. Insync doing most of its operation on AWT event thread is not new and it has been the case all along. We need to do investigation if insync can be re-architected not to use AWT event thread. Therefore downgrading the priority as it cannot be addressed immediately.
They will not show in FCS product. But for JavaONE demo, the following flag should be there, -J-Dorg.netbeans.api.java.source.JavaSource.level=SEVERE
Warnings during project creation are eliminated because of modeling done in a non event dispatch thread. The user may still see some messages upon other actions such as drag'n'drop of components.
See Devas comment: ...Insync doing most of its operation on AWT event thread is not new and it has been the case all along. We need to do investigation if insync can be re-architected not to use AWT event thread. Therefore downgrading the priority as it cannot be addressed immediately. Asking for waiver for M10.
Part of the issue has been addressed in 6.0, because of asynchronous modeling during project creation/open. Due to which the modeling happens in a different thread other than AWT thread. Later user actions like drag and drop of components, renaming ids and things like that still happen on AWT thread. Unless we have a solution to do something userful(for example giving UI feedback) during these actions I do not see we should address this bug. Morever these messages are not shown in user releases. Therefore lowering the priority and targetting for future release.
No current plan to resolve it. Moving to 'later'.