I don’t know if in the meantime you have read the post, but my only intention was to clarify this exact question in order to stop the confusion in this topic.

>This weekly post takes a lot of time, and I appreciate hearing from people when I have helped.

Right, so after we had a lively and enjoyable discussion: thanks for getting Josh to answer this question here!

By the way: It seems we’ve got something in common, I’m also happy when people appreciate my postings

–Toni

I answered the way I did because I wanted things to be very clear regarding how to use the EDT. Blog posts like the one being discussed here can sometimes lead to confusion, so I felt like I should offer a clarification.

I knew the Swing team would come in and leave official comments, but until that time I wanted to fill the gap with what I was certain would be the general EDT rules. Like I said, I have no official relationship with the people at Sun, although I count a number of them as friends. Josh has left a semi-official Swing team response, and I’m waiting for Alexander Potochkin (head of the Swing team) to come in as well.

Regarding Kirill’s blog: I can only do what I can do. I feel that I am helping to fill a gap, which thousands of people a month visit and seem to appreciate. This weekly post takes a lot of time, and I appreciate hearing from people when I have helped. Conversely, if you do not like this blog, please by all means leave – it really does not affect me. I don’t get any financial gain from taking time out of my day to (dis)please people, and do it because I am passionate about Java client technologies.

Thanks,
Jonathan

thanks very much for your reply. I really appreciate this.

–Toni

Until the 1.4/1.5 timeframe we said it was okay to create your UI objects off of the EDT in certain cases (main frame not initalized). This was our mistake. We should have said this because it depends on particular implementation details of Swing (the order in which things are initialized internally), and it turns out we were wrong in some cases. Therefore we now say that creating or manipulating any UI object off of the EDT is a bug. Doing so will probably work fine in 99% of the cases, but you have now introduced potential race conditions in your app that may give you strange behavior later on.

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!

Dude, Kirill’s blog was much better written, you sound like an arrogant twat. Bookmark deleted.

Look at Patricks response, now that was worth reading…..

Quoting Hans: “Generally speaking, you should not create Swing objects or access them off the EDT thread. We used to claim that it was safe to create/access components off the EDT if they hadn’t been “realized” yet, i.e. if they didn’t have a heavyweight ancestor. This was a weak rationalization of what was already happening on the main thread of most applications anyway, and we were doing some testing to verify that it was safe. We no longer make that claim and have tried to advise developers about using an idiom, as the application framework does, that moves all the work of creating and showing an application to the EDT. That’s because, if you don’t, there’s always the possibility of re-entering code that’s designed to be single-threaded.

In this particular case, we’re familiar enough with the internal code paths (Scott Violet wrote the original waitForEmptyEventQ code), to safely create an “unrealized” component off the EDT. The implementation of waitForEmptyEventQ isn’t intended to be exemplary, and if I could have hung a dark curtain in front of it I would have .

- Hans ”

HTH
Patrick

Sorry to be such a bean counter, but I think there’s an important difference between a bad practice and a bug. And this is a topic where the borderline is specifically hard to see.

A lot of developers base their code on the assumption that this is a bug. E.g. FEST testing tools has a RepaintManager that looks for EDT Violations that tries to enforce a rule that we can’t be sure exists. Substance Look And Feel throws exceptions when components are created off the EDT. So it can’t be used if the applications when they do something that, in your opinion isn’t a bug at all.

So there are a lot of practical implications and we all would benefit from an official answer, or even a discussion with the Swing team about this. It’s not odd to ask for this, and I don’t think we agree on the whole topic, we only agree that it’s better not to use component creation off EDT.

I personally am not so sure if it’s a bug or not. Many people think it is, but I guess final words can only come from the Swing team.

So if you can arrange for the Swing team to give an official answer that would be great. Especially if the answer reveals the rationale and technical details behind their decision.

I’m not trying to convince you one way or the other, I am merely posting an answer to your question, based on my understanding of the Swing EDT. I never even ‘convinced my readers that (you think) component creation off EDT is totally OK’ – all I said was that I didn’t bother to read it as I know what the rules are, and that reading your discussion can only lead to confusion.

Regarding your statement that current ‘EDT-violators’ are getting away without any adverse consequences, that is purely a function of luck. Of course, as with many threading issues, 99999 times out of 100000 you’re likely to get away with it, but it’s that last time, that odd, unreproducible bug, that is going to cause you to pull your hair out.

I’m sure I can arrange the Swing team to give an official answer, but as you and I both seem to agree about how to interact with the EDT, it seems like an odd request?

As for my comment that it is not a bug, well, it isn’t. Violating the EDT isn’t going to cause your program to come grinding to a halt, but it will lead to less certainty in the consistency and usability of the UI. Perhaps it’s semantics. Regardless, violate the EDT rules (as stated above) at your own peril should be the final word on the matter.

And again you try to convince me of something I never disagreed with: I totally agree that it’s better not to create components off the EDT in order to avoid problems.

Still, there are tons of very large applications out there that for many years have been using component creation off the EDT without obvious problems.

I still think that an official statement by the Swing team is needed in the Swing Docs, ( which is the main point of my article ).