Bug 168779

Created attachment 84907 [details]
messages.log

Guys from Platform, please look at this issue. Thanks.

Should be evaluated if this is a regression on our side or if the Substance look and feel changed its behavior with a
new check for execution out of EDT. Substance LaF used to work with NetBeans in previous releases without problems.

Reassigning to Dafe for the evaluation.

Substance has changed it's behaviour with version 5.0:

http://www.pushing-pixels.org/?p=368

To my knowledge there's no way to stop the checking.

--Toni

This issue represents the same line of complaints that I've had about netbeans using the EDT thread for non-swing/awt
actions.  There is a growing problem in writing swing applications with lack of a model for managing interaction with
swing vs the-world.  The SwingWorker class in JDK1.6 represents the Swing teams desired mechanism for how to manage the
issues, overall with what is going on.  I think that this is a nobel effort, but I also think that it doesn't take into
account the whole issue of sequences of events that are swing, non-swing, swing, non-swing etc sequences.

I've attached a class which we use for more complex threading control.  There are other types of thread control classes
running around on the internet.  I think it is finally type for the netbeans platform to assert a solution that is
consistent across all modules (over time it can be adopted in old code, as bugs are fixed etc).

Created attachment 85038 [details]
SyncThread java source

To me the real problem is no great guidance from the Swing team and no internal management of their own rules. Basically
MS WIN32, Borland VCL, and others don't force anything down a single thread as it relates to instantiation. This is much
different from some other action being taken off the EDT on an instance after the object is handed into the EDT.

The Swing teams rule used to be that things can take place off the EDT until those things are realized. Seemingly this
changed around the time of Nimbus and all that. Sure, there were some documents here and there, but the examples and all
were not strictly on the EDT with regard to instantiation until some time around those changes, and before that it was
known there were times it was very handy to create things off the EDT as there are other issues with doing that in the
EDT only which will most likely eventually raise their heads as moments of blocked UIs, even if for a second or
two...annoying.

There are great uses cases for object instantiation off the EDT, and it, like many other things when concurrency is an
issue, is up to the developers writing X piece of source code to make sure they don't have concurrency issues. Nimbus
just flat out has a bug in it where it uses the a key set from the UI defaults of swing and iterates over that versus
calling toArray() and iterating over the immutable object. Substance is a different thing altogether, yet part of the
overall issue of bad enforcement and no great sharing of information inside and out of the Swing team; this question has
been boiling around in the community forever, and when many, including new folks in the Swing team, didn't understand
it, it would have been wise to address it.

This really seems to show up in the fact that new Swing developers, Swing team, didn't adhere to the same rules as the
past, and just the same, many outside could not understand the initial rules either, and it points to not enough
guidance apparently. Too, I personally think much of it comes from many not having worked in anything other than Java,
many of which haven't/hadn't done much Swing work regardless, and then they started trying to create responsive desktop
UIs versus web applications. These same issues have been in nearly every UI framework available, and have not posed such
a massive information void and set of issues.

At the end of the day though, the Swing team needs to realize there are many applications out in the world which were
written before JDK 6, and these rules need to be clear, and need take reality into consideration. The main reality is it
is a perfectly valid use case to need to instantiate objects off the EDT to keep UIs from bogging down. Just as there is
a reason for double buffering and creating graphics in the background before they are drawn and processed, there is a
reason to do these other things off the EDT, and this is reflected in the number of applications which have been
creating instances in the bg for years.

Anyways, things like Swing worker and other threading helpers are handy, but they'll never be able to compensate for
actually understanding threading issues. Granted if one does always rely on things being done in a single thread a more
stable library can overall be created by that simple fact, but it doesn't give developers flexibility they may need to
created they best application they can. Depending on a given situation that may be enough to force someone to rely on
something else all togther.

After a further evaluation and discussion the decision is not fix this.

Number of places where we instantiate UI components off EDT before making them visible is much higher than those
reported in this bug. We don't plan to spend our time looking for all such places in our codebase and fixing them, just
for Substance which tries to enforce what even Swing does not dare to enforce by brute force because it would break
compatibility for Java apps with long history of the codebase (like NetBeans).

We recommend to the NetBeans users who want to use Substance to push on Substance to remove the enforcement from their
code, or to make it optional for their users (e.g. using a property to switch it on for those who want).

We will spend our time fixing real bugs in our code rather than refactoring the codebase.

Regarding the property to turn off the strict checking in substance: It has been requested by various users with large
and old code bases but there are currently no plans to do this...

I do understand your reasoning. One of the reasons I submitted this bug was to also get a statement from the NetBeans
team, or even better from someone inside Swing, if or if not component creation off the EDT is to be considered a bug.

If it is, then these are "real bugs", if not, then it's a bug in substance.

Currently there is not much official information, but it's widly considered a bug, even inside the Swing team. It's even
a common question in job interviews for Swing developers. It would really be important to resolve this in some way.

Any place in NB code in which an AWT component is created off EQ is a bug. But there may be no user-visible symptoms
arising from this (except for Substance users), in which case the time required to fix them all would not be well spent
compared to other work we could be doing.

Thanks a lot for your comment Jesse. I'll ask Kirill, if he can provide a property to stop the strict checking.

--Toni

According to Josh Marinacci, the problem with the creation of UI elements off the EDT will become worse in future
releases of swing:

"One more detail, and this is important. As we work to further improve startup time of the VM and the Swing
infrastructure, we will likely change the internals of Swing. This may increase the likely hood that code which used to
work fine off of the GUI thread will now break. Therefore it is *very* important that you stay on the GUI thread; and
that’s why I say: yes, it’s a bug!”

So I guess we should carefully watch this topic.