Java desktop links of the week, July 27

A fairly quiet week this week in Java desktop land, but nonetheless some interesting news. Perhaps everyone is taking a deep breath prior to an Oracle acquisition. Regardless, let’s get straight into this weeks Java desktop links of the week.

General

  • Cutting across both Swing and JavaFX is the need for good UI tests. The FEST project is one of the leaders in this area, and it is growing, with a number of new members this week alone. FEST is now looking to grow support for testing JavaFX user interfaces also.

Swing

  • Željko emailed me to say that his Revolución Movie Library 0.7 beta has been released. This application has been linked to before from here, as it shows off what is possible with Swing. Note that this is a closed source application that’ll eventually not be free, and the current download is a 30-day trial.
  • There is a discussion on whether component creation off of the EDT is really a bug. Frankly I didn’t even bother to read the article, as in my humble opinion it’s simple: anything relating to the UI should be performed on the EDT, and anything not relating to the UI should not be performed on the EDT (unless it is a very quick operation). It doesn’t get much more black and white than that.

JavaFX

Griffon

That’s it for another week – hope you left a little wiser than when you entered. If not, demand your money back. Anywho, tune in next week – same bat-time, same bat-channel.

12 thoughts on “Java desktop links of the week, July 27”

  1. Thanks for linking to my article about component creation off the EDT, but in my opinion it’s always better to read an article before commenting 😉 .

    I agree with you, that when writing an application you should avoid component creation off the EDT. The question I’m rising in my article is if it’s a *bug* or a bad practice.

    I used to think it was a bug until I investigated why this is a bug. There is almost no information except one or two examples (linked in my article) how you can introduce bugs in your application when using it. The component creation off EDT doesn’t cause any problems itself in these samples, the developer introduces them. The only message I get from this is, that it should be used with care.

    The only *real* hint is that one of the Swing examples had problems (linked in my article), and this information is not even officially available, and there’s no explanation if the bug is in Swing or in the use of Swing.

    Creating components off the EDT used to be officially perfectly OK until around release 1.4 of Java. It *seems* to have changed around that time, but there is no official explanation why, and except for a cryptic sentence in a Swing tutorial, there is no info from Sun.

    The intention of my article is to point this out and ask for an official statement from the Swing team, if or if not it is a bug, or just error prone.

    I think it’s an important question, since many large applications with old code bases are still using the old technique without any obvious problems, and it would be hard to change this.

    –Toni

    > Frankly I didn’t even bother to read the article, as in my humble opinion it’s simple: anything relating to the UI should be performed on the EDT, and anything not relating to the UI should not be performed on the EDT (unless it is a very quick operation). It doesn’t get much more black and white than that.

    1. Toni, I’ll answer on behalf of the Swing team, even though I have no official relationship with Sun at all. Doing anything GUI related off of the EDT is not a bug, but it is completely, utterly, and entirely a bad practice that you should avoid at all costs. Ignoring this advice can lead to inconsistencies in the user interface and give both developer and end user no end of grief. Therefore, whilst I still haven’t read your article, let’s not overcomplicate things: as of right now, and for ever and ever onwards, always use the EDT when you’re doing GUI stuff, and never use the EDT when you’re doing non-GUI stuff (unless it’s very quick).

      Any official Swing team response I am certain will be along these lines.

  2. Let me sum this up: First you argued against my article without bothering to read it, giving your readers the wrong impression that I think component creation off EDT is totally OK, now you make an even stronger statement than I ever did saying component creation off the EDT is not a bug at all. 🙂

    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 ).

    1. No, both in my original post and in your subsequent reply I didn’t argue against what you were saying. I was stating the EDT rules as they currently stand, in my opinion. I think it is important that when the question is being raised that someone try to answer it, lest it lead to further confusion.

      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.

  3. If, as you say, the component creation off the EDT is not a bug, then any errors that the ‘edt-violators’ are receiving are a function of bugs in their code. When it’s working, it’s not a function of good luck, but of good coding.

    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.

    1. There was a discussion about this on the Swing App Framework mailing list a couple of years back. Hans Muller (ex of Swing team), responded
      http://markmail.org/message/gjhgs4mw732d64ux

      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

  4. Jonathan, your blog comment/responses are arrogant and rude. Esp if you didn’t even bother to read it! And if you have no affiliation with the Swing team what are you doing answering for them?

    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…..

    1. Ryan,

      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

  5. As a former member of the Swing Team I’m going to go ahead and say that creating UI objects (not just components) off of the EDT is a bug in your program.

    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!

  6. >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 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

Leave a Reply