SWT bloque/se bloque sur Linux, lors du déploiement en tant que Java Web Start

Question

L'application Java WebStart sur laquelle je travaille utilise SWT pour l'interface graphique, et j'ai récemment réalisé un problème petit mais ennuyeux. Lorsque je choisis une action qui utilise un FileDialog, c'est-à-dire enregistrer l'image, l'interface utilisateur se bloque immédiatement après la fermeture de la boîte de dialogue. L'image est enregistrée et peut être ouverte avec une visionneuse d'images par défaut sans aucun problème, mais l'application n'est plus réactive à partir de ce moment, et je suis obligée de tuer l'application.

J'ai remarqué que le résultat est le même quand essayer d'ouvrir un fichier en utilisant un FileDialog, si je préfère ouvrir le même fichier en l'envoyant comme argument en utilisant le fichier jnlp, ça marche bien, donc je ne sais pas pense que c'est un problème avec le système de fichiers local.

J'ai essayé de reproduire le problème sur Windows seulement pour voir que cela fonctionne bien sur Win 7. Comme une deuxième tentative de dépannage, j'ai essayé de sauvegarder une image de la version locale de l'application (en d'autres termes, non -JWS) et ça fonctionne bien aussi ...

Je suspectais un problème d'autorisations sur le fichier jnlp, mais toutes les permissions sont données à l'application, et les signatures sont toutes ok aussi (le fait que l'application commence points à cela). D'ailleurs le fichier image est écrit de toute façon, donc ça ne peut pas vraiment être une chose de permission.

Des idées?

MISE À JOUR: Apparemment, le problème ne dépend pas uniquement de FileDialog, mais de n'importe quel type d'interaction utilisateur graphique. Chaque fois que des fenêtres SWT sont déployées, le programme se fige avec un écran gris, APRÈS n'importe quelle action qui était supposée être faite. J'ai copié du code ci-dessous, dans cet exemple particulier même si je clique sur Annuler, l'application devient non réactive avec un écran gris. Voici quelques exemples de code:

public static boolean saveChangesBeforeDiscard(MyMain main) 
{ 
    if (main.isDirty()) 
    { 
     MessageBox messageBox = new MessageBox(
      main.getShell(), 
      SWT.ICON_WARNING | SWT.YES | SWT.NO | SWT.CANCEL); 

     messageBox.setMessage("Would you like to save the changes?"); 
     messageBox.setText(MyMain.TOOL_NAME); 
     int answer = messageBox.open(); 

     if (answer == SWT.YES) 
     { 
      SaveFileAction save = new SaveFileAction(main); 
      save.run(); 

      return save.isSaved(); 
     } 
     else if (answer == SWT.NO) 
     { 
      return true; 
     } 

     return false; 
    } 

    return true; 
} 

Mise à jour 2: Btw J'utilise Sun JDK 1.6.0. Voici la sortie de la commande java -version:

java version "1.6.0_22" Java (TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot (TM) 64 bits serveur VM (build 17.1-b03, mode mixte)

Answer 1

Si SaveFileAction.run() prend beaucoup de temps à s'exécuter, cela peut expliquer le gel de l'interface utilisateur.

Dans SWT, il est de votre responsabilité de faire fonctionner la pompe d'événements. En général, il ressemble à quelque chose comme:

while (!shell.isDisposed()) { 
    if (!display.readAndDispatch()) { 
    display.sleep(); 
    } 
} 

Mais parce que SWT est mono-thread, un seul événement est traité à la fois. Ainsi, si un écouteur d'événement prend beaucoup de temps à s'exécuter, l'interface utilisateur ne sera pas disponible tant que l'écouteur n'aura pas terminé et que le contrôle ne sera pas retourné à la pompe d'événements.

Lorsque des opérations de longue durée sont requises, la pratique recommandée dans SWT consiste à effectuer l'opération dans un thread de travail, en envoyant des mises à jour asynchrones à l'interface utilisateur, comme requis. sur la FAQ SWT

executor.execute(new Runnable() { 
    public void run() { 
    showStatusMessage("Saving "+filename+"..."); 

    SaveFileAction save = new SaveFileAction(main); 
    save.run(); 

    showStatusMessage("File "+filename+" saved.") 
    } 

    private void showStatusMessage(final String message) { 
    Display.getDefault().asyncExec(new Runnable() { 
     public void run() { 
     statusLine.setMessage(message); 
     } 
    }); 
    } 
}); 

This entry explique le modèle de filetage plus en détail.

Answer 2

Il y a un bogue dans SWT qui provoque ceci: here

Le bug a été résolu récemment - voir le bug pour plus d'informations.

Answer 3

J'ai juste eu un problème similaire. Je l'ai résolu en lançant le fichier jnlp avec IcedTea Java 6 Webstart (OpenJDK's javaws) au lieu de javaws d'Oracle.