L'utilisation de JavaFX Plate-forme.runLater et l'accès à l'INTERFACE utilisateur à partir d'un autre thread

J'ai quelques questions à propos de Platform.runLater. J'ai un JavaFX Application de classe. Dans cette classe, je lance un thread (thread lit les données à partir d'une prise réseau).

Maintenant, quand je créer un nouveau Stage à l'intérieur du fil, le système déclenche une exception (JavaFX répartiteur d'évènement de fil et mon netork-lire fil ne sont pas les mêmes) - je comprendre ce comportement.

Mais de l'autre côté, j'ai ajouter le texte à partir du réseau-lecteur à un TextArea ou ajouter/supprimer des éléments dans un ListView<String> - ce n'est pas de jeter une exception, pourquoi ? Je pensais que JavaFX est single thread (La bibliothèque d'interface utilisateur). Est-ce la même chose que dans les Swing: Parfois ça marche et parfois vous avez juste à ordures (Parce que HAE)?

Mes questions:

  • Quand le JavaFX répartiteur d'évènement fil lever une exception et quand pas ?
  • Sont tous de bons documents à propos de cette
  • Est-il plus facile (plus court & cleaner) façon d'utiliser Platform.runLater avec un run() méthode ? En combinaison avec un try catch (ou plusieurs prises), il semble très étrange

Je sais que l'utilisation de Platform.runLater dans un thread n'est pas que belle (solution de conception)

Or is this the same thing as in Swing: Sometimes it works and sometimes you have just garbage? s'il vous plaît que pensez-vous en train de parler, toutes les mises à jour de la Balançoire interface graphique doit être fait sur l'EDT, unique dangereux pour l'interface graphique est un avantage dans la plupart des cas, appliedd pour beaucoup de GUI de cadres dans divers langages de programmation
Oui, je veux dire EDT en Swing (il suffit d'utiliser l'INTERFACE utilisateur dans l'EDT contexte). Je veux dire, que lorsque vous accédez à un Swing de l'INTERFACE utilisateur à l'extérieur de l'EDT, parfois ça marche et parfois pas
Veuillez inclure dans votre question, un exemple de code montrant In combination with a try catch (or multiple catch), it looks very strange.

OriginalL'auteur swaechter | 2013-03-01

  1. 10

    "ce ne jette pas une exception, pourquoi?" parce que tous ces cas sont cought... peut-être, en raison de considérations de performance, éventuellement, c'est juste une fonctionnalité manquante.

    Toutes les interactions avec JavaFX objets (y compris la création) doit être fait sur JFX fil, si vous souhaitez accéder à ces JFX des objets à partir d'un autre thread - utilisation runLater ou runAndWait méthodes. Si ce n'est pas jeter l'exception maintenant, il va commencer à lancer des exceptions dans l'avenir. Toute interaction avec JFX objet peut provoquer une ultérieure des actions et des événements, qui sera intercepté par du fil checker - vous ne pouvez pas être sûr.

    Je ne pense pas, il y a une bonne documentation sur ce - juste une règle simple - utiliser runLater ou runAndWait.

    Plus court et le moyen le plus propre, sera fournie dans le JDK 8 utilisation Lambda.

    Ok, je vous remercie. Bon à savoir - je vais utiliser la Plate-forme.runLater. En ce qui concerne le JDK 8 - malheureusement je ne peux pas attendre jusqu'à septembre 2013 🙁
    Vous pouvez télécharger son aperçu. En fait, vous pouvez commencer à utiliser le JDK 8 sur votre risque. Et il contient lambda, autant que je sache. jdk8.java.net/download.html

    OriginalL'auteur Alexander Kirov

  2. 16

    D'alexandre de répondre à des captures les points les plus importants concernant vos questions.

    Cette réponse fournit quelques informations supplémentaires.

    Quand le JavaFX répartiteur d'évènement fil lever une exception et quand pas ?

    En Charge le système ne permet pas de toujours vérifier que les accès aux objets affectant l'actif de la scène graphique est limitée à la JavaFX fil. En fin de compte, assurer la sécurité des threads est de la responsabilité du programmeur d'application JavaFX - pas en Charge le système. Vous devez être très prudent lors de l'exécution de multi-thread de programmation en JavaFX, sinon comportement de l'application peut échouer ou devenir imprévisible.

    Sont tous de bons documents à propos de cette

    Essayer le JavaFX tutoriel: La simultanéité dans JavaFX.

    Est-il plus facile (plus court & cleaner) de façon à utiliser la Plate-forme.runLater avec une méthode run ()?

    Pas. Platform.runLater est aussi simple que cela.

    Que d'un côté . . .

    Tâche et de Service

    Envisager l'utilisation de la Tâche ou Service des sous-classes de Travailleur. Ce sont JavaFX des wrappers pour FutureTask (qui est à son tour un Praticable). Les travailleurs de fournir un appel méthode à exécuter logique sur un thread d'arrière-plan. Ils maintiennent l'exécution statut (avec thread-safe callback de notification à la JavaFX fil pour les modifications de l'état) et de retourner des résultats de l'appel à l'aide de valeur, message et exception propriétés.

    Profiter des modèles de conception dans le Task et Service javadoc exemples de simplifier la création de thread-safe applications avec des fonctionnalités telles que:

    • Asynchrones extraction de données pour l'INTERFACE utilisateur de mise à jour.
    • Périodique des messages de mises à jour pour l'avancement de la tâche.
    • La construction de Nœud graphiques qui sont pas encore attaché à une affiche de la scène.
    • Le suivi des progrès réalisés par les barres de progression, etc.

    Un Worker est complémentaire à Platform.runLater. Utilisation Platform.runLater lorsque vous exécutez hors de la JavaFX Application Thread et que vous souhaitez exécuter une certaine logique sur le JavaFX application Thread. Utiliser un Worker lorsque vous êtes en cours d'exécution sur le JavaFX Application Thread et voulez lancer un peu de logique ou (et surtout) I/O sur un nouveau fil de sorte que vous ne bloquez pas le JavaFX Application Thread. Vous ne voulez jamais à faire des e/S réseau à l'intérieur d'un Platform.runLater's run méthode, mais souvent envie de le faire dans un Worker's call méthode.

    Aussi, l'utilisation de Task et Service n'est pas incompatible avec l'utilisation de Platform.runLater. Par exemple, si vous avez une très longue course Task à partir de laquelle vous voulez renvoyer des résultats partiels de l'INTERFACE utilisateur, périodiquement ou comme un tampon se remplit, puis l'exécuter Platform.runLater dans la tâche call méthode est la manière de le faire.

    Travailleurs sont utiles lorsque vous ne disposez pas d'un filetée service fourni par une bibliothèque, mais plutôt de créer vos propres threads de s'exécuter en arrière-plan. Si vous avez un filetée de service, alors vous aurez besoin d'utiliser Platform.runLater d'exécuter la logique sur le JavaFX application thread.

    Notez que vous devez toujours savoir ce que vous faites, même si vous utilisez un Worker. Vous devez toujours prendre soin de ne pas violer la norme JavaFX règles de cumul, jamais la mise à jour des Nœuds sur le graphe de scène (y compris pas de mise à jour des valeurs des Nœuds dans l'actif du graphe de scène sont liés à l'tels que les observables de la liste de les éléments à l'appui d'une ListView).

    Ok, merci beaucoup pour cette explication, j'ai besoin d'un certain temps de lire cet article et de faire quelques codetests

    OriginalL'auteur jewelsea