Created attachment 58390 [details]
Module suite project showing the issue.

In order to reproduce the problem please use the attached module suite project.

1) Create the test TopComponent:
File->Create Top Component

2) Drag the created TopComponent

As you can see a TableModel is used from a non-EDT. This is forbidden since all swing models are not thread safe (they 
cannot be thread safe because getting the size of the model and the values are done in at least two different calls 
and are therefore not atomic). I reported bug 128582 which is a similar problem. Please do take these threading issues 
serious and fix them. If they are not fixed, reliable applications cannot be built on the netbeans platform.

Best regards,
Martin Goettlicher

Passing to Standa.

We do take these bugs seriously. But as I explained in 128582 and duplicate, we simply can't get rid of constructing GUI
outside ED thread - startup would take ages then and nobody would be building atop of NB platform. If this is so big
problem for you, we'll happily accept patches, if they don't hurt startup performance. Please understand it - startup
performance is very top priority for us.

*** This issue has been marked as a duplicate of 128324 ***

I don't think that it is a wise decision to trade speed for bugs. You are not only constructing your GUI outside the 
EDT during startup, you are also modifying GUI components while the program is running. Take the 
CheckThreadViolationRepaintManager, open the Options->Font&Colors dialog and see what happens.

To dsimonek:

Please don't get me wrong. I appreciate your work, but for our customers startup time isn't that important. They run 
our application (controlling some expensive equipment) for several days without restart. Therefore we are much more 
concerned about runtime bugs. Some time ago we had a swing threading problem. The code was running for several years 
on a single core system without problems but on a multicore system the program fails because a boolean property set 
outside the EDT (which was wrong) was not recognized by the EDT. In addition I'm in doubt that the program will 
benefit from using additional threads for GUI construction on a single core machine since there is only one execution 
unit and thread context switches cost additional time. On a multicore system you may see a runtime advantage but you 
risk bugs (as we learned).

As a compromise I would like to propose that you add a property (e.g. org.netbeans.use_edt_for_swing) which then can 
be set on the command line to toggle the behavior. It should be cheap during runtime (only one additional compare 
operation) and reasonably easy to implement:

SomeSwingRunnable r = new SomeSwingRunnable();
if (useEDTForSwing) {
    r.run();
} else {
    // Your RequestProcessor based code as before
}

Best regards,
Martin Goettlicher