0

I have java fx application with many tableviews. How we knows in javafx tableview there is databinding, which working in two directions. So when my application making a calculcations with my data from tableviws UI is freezing, because my application constantly updates data from tableviews(ObservableList). I did tried to use Platform.RunLater, but it didn't helped me. Any ideas?

Ivan Timoshin
  • 601
  • 9
  • 23

1 Answers1

2

Platform.runLater essentially delays your runnable - but it will yet again run on the UI-thread hence block every user input during execution.

The solution is quite simple, use a worker thread : 

Task task = new Task<Void>() {
    @Override public Void call() {
        static final int max = 1000000;
        for (int i=1; i<=max; i++) {
            if (isCancelled()) {
               break;
            }
            updateProgress(i, max);
        }
        return null;
    }
};
ProgressBar bar = new ProgressBar();
bar.progressProperty().bind(task.progressProperty());
new Thread(task).start();

Although it is advisable to use the ExecutorService class since it allows for a more controlled behaviour : http://java-buddy.blogspot.de/2012/06/example-of-using-executorservice.html

specializt
  • 1,913
  • 15
  • 26
  • As i understand, your example will be work if i want update my UI periodically and a count of these updatings will be limited. But i want to update my UI while my calculations executing. UPD: Thank you! It's really works! – Ivan Timoshin Apr 29 '15 at 11:48
  • no problem - you can have your task running forever if that is a requirement, there are no limits on the execution time, its just an example. If you stumble upon "Not on FX application thread" exceptions the solution is also quite simple : wrap the offending function call (_nothing else!_) into `Platform.runLater` – specializt Apr 29 '15 at 11:55
  • 1
    `Platform.runLater(...)` does not necessarily delay the runnable in any observable sense; in fact, if your application is well structured, it will run by the very next UI rendering frame. The method name just indicates that the call is asynchronous, so code execution will continue after the call to `Platform.runLater(...)` but before the runnable is likely to have finished. – James_D Apr 29 '15 at 11:59
  • nobody was talking about `observable` effects, what is your point? If you open the sourcecode of `runLater` and follow a few of its calls you will see that the runnable is placed into a queue so it will **always** run at some unspecified time in the future _(read : be delayed)_ - which depends on your current UI-thread "load" and may very well occur in the very next rendering phase. – specializt Apr 29 '15 at 12:05
  • 1
    Assuming you call `Platform.runLater(...)` from a thread other than the FX Application Thread, then there is really no guarantee that your runnable will happen "later" than it would if it were called on the current thread. In the language of the JLS, there is no "happens before" relationship between the return from `Platform.runLater()` and the return from the runnable's `run()` method. It would be perfectly legal, though very highly unlikely, for a thread scheduler to perform its scheduling in such a way that the runnable completed before the return from `runLater()`. – James_D Apr 29 '15 at 12:13
  • My general point though is that "delayed" seems a bit misleading, because I've seen it scare programmers who don't want to use it because they think it will result in a perceivable delay from the user's perspective. It won't (assuming the FX Application Thread is not otherwise flooded). Absolutely nothing wrong with your answer, I just wanted to clarify your use of the word for those who might not be familiar with threading terminology. – James_D Apr 29 '15 at 12:14
  • thats entirely wrong - `runLater` does not return until the runnable has been _queued_ - it _may_ start immediately after that **but** it will **never** run before the queue has finished inserting the element since it is a `BlockingQueue`, please do not state your assumptions like they were facts, thank you very much. – specializt Apr 29 '15 at 12:31
  • I didn't say it would run before the queue had finished inserting the element, I said there was no guarantee it would run before `runLater()` returned. On the current thread, the runnable is queued (A), then `runLater()` returns (B). On the FX Application thread, the runnable is executed (C) and its `run()` method returns (D). The "happens before" relationships are A < B and A < C < D. There is no "happens before" relationship between B and C, or B and D. "Delayed" to me implies a "happens before" relationship of B < C, which is not guaranteed. – James_D Apr 29 '15 at 12:46
  • i just did the proof on a piece of paper -- `take` inside of thread 2 happens after `return` on thread 1. It is impossible for `take` to finish before `add` or `put` have finished since its a `BlockingQueue` – specializt Apr 29 '15 at 13:57
  • I don't really see any theoretical reason preventing `take` from happening after `put` (which as you state must be the case) but *before the `runLater` method returns control to its caller*. However, this is not a particularly interesting discussion, especially as your tone is so aggressive. – James_D Apr 29 '15 at 22:37
  • i dont think you would even understand the explanation as you obviously lack basic knowledge about programming languages and computer processors. Just take this with you : it is not possible for `blocking` field-accessors to break their own, guaranteed order of sequence - that'd basically make the according field nonfunctional and create exceptions of various kinds. Another thing : `return` is one of the fastest operations in existence since it may be translated to a simple `MOV`, there are platforms on which `return` uses only one single processor tick. Thats your "reason". Reality vs theory. – specializt Apr 30 '15 at 08:36