Instance unique d'un programme (sans sockets ni fichier temporaire)

[Chatbour]

Salut à tous et à toutes

voici mon idée : une classe <InstanceUnique> tente de renommer un jar <Application.jar> et SI elle réussit ALORS elle restaure l'ancien nom et lance l'application, SINON on sait que l'application est déjà lancée donc on affiche un message..

Code :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
/*
 *  Classe:     InstanceUnique
 *  Auteur:     Chatbour
 */
 
import java.io.IOException;
import java.awt.Desktop;
import javax.swing.JOptionPane;
 
public class InstanceUnique {
    // nom du fichier jar
    private String nomJar = "application.jar";
    // nom temporaire
    private String nomTmp = "app_tmp.jar";
 
    public InstanceUnique() {
        try {
            File leJar = new File(nomJar);
            if(leJar.renameTo(new File(nomTmp)) == true) {
                // On est le premier à instancier l'application
                new File(nomTmp).renameTo(new File(nomJar));
                Desktop.getDesktop().open(leJar);
            }
            else {
                // Sinon afficher un message
                JOptionPane.showMessageDialog(null, "L'application est déjà lancée !");
            }
        }
        catch(IOException e) {
            System.exit(-1);
        }
    }
 
    public static void main(String[] args) {
        new InstanceUnique();
    }
}

Dans le zip joint il y a une petite démonstration..

Qu'est-ce que vous en dites ?

[tchize_]

magnifique Faudra que tu précise juste

1) qu'est-ce qui te fais croire que l'impossibilité de renommer implique nécessairement que l'applicaition est lancée? (Le fichier peut être read-only par exemple ou pas de droit d'accès)
2) qu'est-ce qui te fait croire que, quand l'application sera lancée, le renommage est impossible?

Les fichiers de lock dans le répertoire temporaire, çà reste le plus efficace.

[Chatbour]

Envoyé par tchize_

magnifique Faudra que tu précise juste

1) qu'est-ce qui te fais croire que l'impossibilité de renommer implique nécessairement que l'applicaition est lancée? (Le fichier peut être read-only par exemple ou pas de droit d'accès)
2) qu'est-ce qui te fait croire que, quand l'application sera lancée, le renommage est impossible?

Les fichiers de lock dans le répertoire temporaire, çà reste le plus efficace.

1. Franchement je n'ai pas pensé à ça
2. A ce que je connais ce n'est pas possible.. Non ?

Je précise que c'est une solution "débutant" qui fonctionne lorsque l'exécutable de l'application n'est pas read-only

Enfin, merci bien pour ton commentaire constructif

[tchize_]

Envoyé par Chatbour

2. A ce que je connais ce n'est pas possible.. Non ?

Sous windows, non, mais java est multi plateforme. De plus comme ce comportement sous windows (auto locking des fichiers ouverts) fait plus chier qu'autre chose, rien ne garantit que ce ne sera pas fixé

[Chatbour]

OK, merci pour l'explication
un point de moins pour mon idée

[adiGuba]

Salut,


+1 pour tchize_

Sans compter qu'un fichier temporaire peut être marqué "delete on exit" et qu'une socket est automatiquement fermé à la fin du process.

Alors que dans ton cas si le fichier n'est pas renommé correctement à la fin du programme tout est bloqué

De plus un utilisateur peut avoir le droits d'exécuter un programme mais pas de le renommer !


a++

[Chatbour]

Envoyé par adiGuba

Salut,


+1 pour tchize_

Sans compter qu'un fichier temporaire peut être marqué "delete on exit" et qu'une socket est automatiquement fermé à la fin du process.

Alors que dans ton cas si le fichier n'est pas renommé correctement à la fin du programme tout est bloqué

De plus un utilisateur peut avoir le droits d'exécuter un programme mais pas de le renommer !


a++

Merci pour le commentaire adiGuba

je trouve comme même que cette solution (dans le cas où les droits de renommer est fourni) est "meilleure" que celle avec les fichiers temporaires : le risque de ne pas renommer le fichier dans ma solution est beaucoup plus inférieure que le risque de ne pas supprimer le fichier temporaire, vous trouvez pas ?

[tchize_]

Normalement, quand on utilise un fichier temporaire, on le lock, on se contente pas de voir si il existe. Si l'application qui l'a créé est arrêté mais a oublié de le nettoyer, y a plus de lock dessus. Par contre, si elle l'a locké et qu'il l'est toujours, c'est que l'application tourne encore!

Pour faire des lock en java, il faut passer par l'api des FileChannel et utilise tryLock()

[adiGuba]

Envoyé par Chatbour

je trouve comme même que cette solution (dans le cas où les droits de renommer est fourni) est "meilleure" que celle avec les fichiers temporaires : le risque de ne pas renommer le fichier dans ma solution est beaucoup plus inférieure que le risque de ne pas supprimer le fichier temporaire, vous trouvez pas ?

Qu'est-ce qui me prouve que le fichier sera bel et bien renommé à la fin ?


Tandis qu'avec un fichier temporaire il suffit d'utiliser un deleteOnExit() pour qu'il soit supprimé automatiquement à la fin du programme, même en cas d'exception. En fait je ne vois que 2 cas particulier (à ma connaissance) où cela ne fonctionnerait pas :

• Sous Windows si le fichier est utilisé par un autre processus (fichu système de fichier )
• Si la JVM se plante méchamment (pas un exception mais bel et bien un plantage)

Maintenant si tu veux un système plus évolué tu peux peut-être te tourner vers les FileLock, mais attention car le fonctionnement est également dépendant du système...


a++

[tchize_]

depuis la doc de deleteonexit:

Note: this method should not be used for file-locking, as the resulting protocol cannot be made to work reliably. The FileLock facility should be used instead.

[adiGuba]

Le filelocking consiste à interdire l'accès à un fichier aux autres processus... on ne fait pas du filelocking ici !

a++

[Chatbour]

OK merci bien les gars

je vais essayer ce que vous avez dis : dommage que ma solution ne soit pas fonctionnelle mais je suis heureux que ça soit une occasion pour moi pour apprendre de nouvelles choses

Merci encore pour vos commentaires constructifs..