0

we have a strange problem with our GUI after changing to Java 1.7.

Sometimes if the user starts our Application it seems to be freezed, but probably there is just no repaint, because if user tries for example to scroll, changes the window and comes back to application the scroll changes are visible.

And the problem will be solved if the users change to fullscreen.

I tried to search for this problem, but the only thing most related to it was an unanswered question here:

http://www.java-forums.org/awt-swing/31107-intermittent-freeze-javawebstart-swing-app.html

May be anyone of you had the problem and know the solution?

Tima
  • 12,765
  • 23
  • 82
  • 125
  • 1
    Please, show code of GUI creation. – alex2410 Apr 15 '14 at 09:22
  • 4
    smells like an EDT rule violation – kleopatra Apr 15 '14 at 09:24
  • 1
    May be anyone of you had the problem and know the solution? --> (agree with both comments) there aren't Thread Safe methods for Swing APIs in Java7, are removed – mKorbel Apr 15 '14 at 09:43
  • > there aren't Thread Safe methods for Swing APIs in Java7, are removed -> what was removed? – Tima Apr 15 '14 at 10:03
  • 1
    removed were documentation errors that incorrectly marked some methods as thread-safe ;-) The first step in solving the problem is to make sure _each and every access_ to swing properties (including models!) happens on the EDT. – kleopatra Apr 15 '14 at 11:17
  • 1
    btw, if you want to communicate with a commenter, you have to address him/her directly, like f.i. @mKorbel – kleopatra Apr 15 '14 at 11:18
  • 1
    `removed were documentation errors that incorrectly marked some methods as thread-safe` - hmmm I can't resist, I think not true about were incorectly marked (talking only and about AWT/Swing APIs), because most of Thread Save methods(many times here discused in last year) valid for Java6(e.g. setText, append), doesn't required EventDispatchThread returns true in Java6, those methods aren't longer Thread Safe and don't work without invokeLater in Java7, simple example setText (and another methods in marked as Thread Safe) from Runnable#Thread doesn't required invokeLater as notifier for EDT – mKorbel Apr 15 '14 at 11:32
  • @all assume, the former thread safe methods are not thread safe anymore. But why then these freezes occur sporadically? – Tima Apr 15 '14 at 12:14
  • 1
    @mKorbel _especially_ the textComponent related methods were incorrectly marked as thread safe ;-) And yeah, it has been discussed to death and all those discussions don't matter: documentation rules - whatever isn't marked as thread-safe **now** **must-not** be accessed off the EDT. Bet my soul on the OPs problem being an EDT violation ... and there're exactly **zero** ways around but removing those violations. – kleopatra Apr 15 '14 at 12:43

1 Answers1

1

The migration to Java 7 may have exposed a latent problem in the original code. Here are some things to look at:

  • Some APIs, especially among the text components listed here, are no longer marked thread safe in Java 7.

  • You can search for EDT violations using one of the approaches cited here.

  • Resizing the enclosing Window generates an automatic repaint(); if your updates are otherwise correctly synchronized, you can sequence your own repaint() using invokeLater().

  • Verify that setVisible() is last in your initialization, after pack().

Community
  • 1
  • 1
trashgod
  • 203,806
  • 29
  • 246
  • 1,045