abillconsl wrote:when i referred to swing above, i meant swing/awt, because the two are pretty much intrinsically linked.jtahlborn wrote:I have always only been talking about AWT in this thread/topic. And I mean all the way back to Java 1.0.abillconsl wrote:jdk 1.2 has SwingUtilities.isEventDispatchThread(), so i'm not sure how far back you're talking about. jdk 1.1 is a long time ago, so i don't think this whole "single threaded ui is a new-fangled thing" idea really holds.gimbal2 wrote:Oh I know! However, what I meant in my previous-previous comment was that, before swing - or early on with swing because swing was sooooooo slow at first (partly because our PCs were so comparitively slow) I did my GUIs mostly in AWT. I always just did background work from any old 'other' Thread and updated the GUIs from there - it always worked and still does. At some point in time, though, apparently the thinking on this has changed. If I was wrong all along, then I was wrong all along - certainly would not be the first time. But I never read differently and I was trying to see when and why that has changed and could not locate any authoritive write up on the subject. Note that I am only talking about AWT.
Swing is and never was thread safe and has always been advertised as such, even if under the hood it just happened to be in some cases/implementations.
as mentioned in my comment above, swing has been "single threaded" for "yonks", so i'm not sure why anyone would be caught off-guard.This again hooks into the fact that Oracle does not seem to care about backwards compatibility or communication though and it is starting to royally annoy me. Okay perhaps the code wasn't exactly right even for Java 6 because it assumed thread-safety, but when changes are handled like this even people who have worked with Swing for yonks are caught off-guard. What are we supposed to do? Compare the code of the runtime with each new release of Java just to stay up to date!?
Each time there is an update now it seems something breaks ... or at least does not work just the same. There's always been some of that, but I do think it's worse. On my mind is all the talk about security issues for Applets ... but that's just as much (or in fact mostly) hackers turning their attention to it as it is the fault of Oracle probably ... though I say that not knowing if hackers were working on this for a long or a short time, and not knowing either any of the internal changes that lead to the problems.while i won't disagree with the general thought that oracle seems less concerned with breaking backwards compatibility, constraining the jvm to continue to support old thread-unsafe behavior would probably have kept the jvm in the stone ages. i personally like the current performance of the jvm and don't wish for the return of the "performance" of the 1.1 days.
abillconsl wrote:Yes, I know, wiki...
Yes, but as I kept saying, Everything I can remember ever reading about the event dispatch model had to do with swing.
And as I also stated, I could very well mis-remember.
That was the only reason I mentioned not being able to locate material that SPECIFICALLY referenced AWT when speaking about the EDT.
Tolls wrote:My annoyance turns to deep disappointment. I mean where is the limit, now I have to assume in JDK 8 such breaking changes are done to standard APIs that are still widely used.
So it's not a case of utilising an undocumented feature of Swing, but of the latest releases removing a feature that was documented.
gimbal2 wrote:From posts on the site it doesn't seem like Oracle is as concerned about what might break with new builds, much less releases, versus what Sun used to do.
It is just an idiotic move, unless you are on some sort of mission to get people to drop the API altogether.
EJP wrote:Except it's been removed from the documentation.So it's not a case of utilising an undocumented feature of Swing, but of the latest releases removing a feature that was documented.Guys, this is a BUG. Report it!