java - The Necessity of dispatching simple events with the EDT -

before go on discussing basic query first state aware of question being against standards of awt/swing framework. query meant merely academic experience , should (hopefully) never applied real world applications.

the awt/swing framework built upon event based model uses single thread dispatch events. awt/swing related events events must processed on event dispatcher thread (edt) , custom events programmer has programmed must queued through functions invokeandwait() , invokelater(). while model ensures framework never suffers sort of thread concurrency issues gives big pain programmers trying write code around (search swing issues on stackoverflow... quite handful).

however... years ago, before got more familiar awt/swing model , edt used write code violates many many java standards (code that'll make reasonable programmer recoil in horror). 1 of these standards violated calling methods updated gui through thread thats not edt. precise standard "long" task resided on secondary thread periodically updated jlabel current progress. reviewing code realized despite fact code directly violated standard, worked 100% of time. noticed no flickering, no corruption of text (since jlabel), no random exceptions being thrown , no abnormal gui behavior. of course know 1 tiny example, 1 cannot determine awt/swing standards over-protective or unnecessary. , this, query lies:

for simple tasks updating jlabel (not @ constant rate, maybe once or twice second) necessary perform through edt? , possible implications (apart being despised whole java programming community) of (i want list of solid implications, not "it might cause edt mess up")?

assume model 1 thread updates gui (which not edt) , updates infrequent , update in atomic operations (updating strings, primitive data, etc) possible program can run free of problems caused edt (i guess counts hack?).

as challenge, wondering if possible can come code demonstrates violation of awt/swing model dispatching events thread causing obvious , constant (as in don't have wait 2 hours gui flicker 1 frame) problems?

and way, might unrelated new edt thread spawn new jframe/window object or of them run off same thread? can't imagine resource-heavy multi-window system running off 1 thread.

nb: have never seen nor analyzed source code of awt/swing framework , knowledge based on internet research , personal experience. if there mistake above, please feel free correct me. programmers still in shock example above, have updated projects comply standard (what pain).

an example of fails: set jlabel right-aligned. drawing requires 2 steps - measuring text, in order calculate position, , drawing it. if change text while painting (say, due animation loop) text seem jump occasionally.

in answer other question - there 1 edt, gui components.

example of "constant , obvious" change: suppose jlabel has html content. in background thread, after text set , repaint fired, propertychange fired, causes ui delegate reparse html , set in client property (working in background thread, although ui assumes in edt because receiving event).

so have race condition: if ui repaints label (in edt) before finishes calculating html view in background thread, paint old html , label appear not update.

you say, "well then, won't use html in label." point situations pervasive in swing libraries - strong assumption made everywhere events passed on edt, , without reading huge amount of swing source can't guarantee won't run problem this.