Discussion :

[Caxton]

Salut tout le monde.
Je suis sur un autre problème auquel je n'ai pas su trouvé une réponse convenable. Je cherche à trouver le path de l'application qui s'exécute.

Voila ce que j'ai mis:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
private void jMenuItem7ActionPerformed(java.awt.event.ActionEvent evt) {
        // Trouve le path de l'application java
        String urlApplication = new File().getAbsolutePath();
        jTextArea1.setText("L'application est présente sous: " + urlApplication + "\n");
    }

L'arborescence est situer comme ceci:

D:/
+-Java
| +-Application.jar

Ce qui fait que urlApplication devrais me renvoyer D:/Java/ auquel j'ajouterais une concaténation pour accéder aux autres fichiers que je manipulerais dans mon application.

Autrefois en c++, j'utilisait ceci:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
AnsiString Filepath;
Filepath = ExtractFilePath(Application->ExeName);

Et donc je cherche une &quivalence si elle existe
Cordialement

[tchize_]

new File() va te retourner le répertoire courant, qui n'a rien à voir avec le classpath de ton application:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

System.getProperty("java.class.path");

Plus de détails sur les propriétés système ici
http://java.sun.com/j2se/1.5.0/docs/...getProperties()

[Caxton]

Pour le moment je ne suis plus sur les Properties
J'ai juste besoin de trouvé le path de mon application depuis l'application compilé. Ce qui fait que si je déplace mon jar, dans E:/Java, le contenu de ma variable change aussi.

[Caxton]

Bon et bien j'ai essayer ta méthode Tchize_ et elle ne se compile pas
Une autre solution pour avoir un emplacement à la racine de l'application compiler ?

[tchize_]

Bon et bien j'ai essayer ta méthode Tchize_ et elle ne se compile pas

Si tu veux le classpath, c'est comme ça qu'il faut faire. Et j'ai du mal a voir pourquoi ca ne compilerais pas. La doc de System.getProperty est là:
http://javasearch.developpez.com/j2s...va.lang.String)

et L'ensemble des propriétés de base est décrite ici:
http://javasearch.developpez.com/j2s...getProperties()

[Caxton]

Alors la je suis un
Effectivement, ça compile et ça fonctionne

L'application est présente sous: D:\DevJava\TestFichier\dist\TestFichier.jar

Maintenant j'ai une nouvelle question... Il fallait s'y attendre
Comment je puis retrouver seulement "D:\DevJava\TestFichier\dist\" et sans le "TestFichier.jar"?

Sinon on a presque la solution

[tchize_]

tu va devoir traiter ton classpath à la main. Ne perd pas de vue non plus que, suivant l'application java, tu peux avoir plusieurs emplacement pour ton classpath. Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

/home/tchize/myApp/bin/myApp.jar:/home/tchize/myApp/lib/log4j.jar:/usr/local/java/native/MyNativeLibrairy.jar

Bref, il n'y a pas de règle générale. Contrairement à un exe windows, les application java n'ont pas d'emplacement précis, juste un ensemble de librairie et une classe Main.

Tu peux aussi jouer avec ta class Main et faire un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

URL u = Main.class.getResource(".");

reste après à manipuler ton u pour déterminer où se trouve ton application.

[Caxton]

A ce moment la, il faudrait que dans le jar, il soit installé un path vide dans un properties. Au lancement de l'application, on teste ce path, si il est vide, on lance un wizard qui initialise à l'endroit voulue par l'utilisateur. Et j'utilise un jFileChooser pour récupéré le dossier. Ceci m'évitant de choisir pour l'utilisateur. D'autant plus que certains utilisateurs ont plusieurs disques dur et ne sont pas sous windows mais sur linux et free bsd.

Qu'en pensez vous ?

[tchize_]

Le plus simple à mon avis, c'est de'nregistrer cette information au moment où l'utilisateur installe ton application. Il suffit alors de faire un installeur qui va

copier les jars à l'endroit voulu par le user
créer des fichiers .bat et .sh ayant la ligne de commande pour lancer l'application
stocker dans ces .bat et .sh un paramètre du style "-DApplicationHome=..."

Le tout dependant bien sur de ce que tu veux faire de ce chemin.

[Caxton]

Et bien en fait il me permet de gérer ensuite les données préférences utilisateur ainsi que les projets créer par l'utilisateur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
 
D:/
+ProgrammeBuilder
           +ProgBuilder.jar //Mon applicarion
           +lib
           +Preferences.properties
+Dossier de travail //Le dossier que je crée pour mettre tout mes travaux créer par mon application
           +Projet1
           +Projet2
           +Projet3

C'est donc pour cela que je compte avoir le path au final du répertoire qui contiendra le path D:/ProgrammeBuilder/ pour accéder directement à Preference.properties, quelque soit l'endoit ou on place le jar. De plus ce properties contient le path de chacun des projets.

A moins qu'une autre solution soit plus facile, je comptais faire cela.

[tchize_]

Pour le projets, a priori c'est à l'utilisateur de choisir. Pour le sotckage des préférences, il existe deux possibiltiés courement utilisée et que je te recommande par cohérence avec les autres applications du marchés.

soit utiliser <System.getProperty("user.home")>/.NomApplication/config.properties
soit utiliser l'api de Preference inclue dans java (plus facile et mieux intégrée à l'os).

Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
import java.util.prefs.Preferences;
 
//....
 
Preferences applicationUserPreferences = Preferences.getUserRoot().getNode("MyCompany/MyApplcationName");
String[] lastOpenNodes = applicationUserPreferences.getNode("recentlyOpened").getChildrenName();
for (String recentFileNode : lastOpenNodes){
    String fileName = applicationUserPreferences.getNode("recentlyOpened").getNode(recentFileNode).get("location","unknown");
    String when = applicationUserPreferences.getNode("recentlyOpened").getNode(recentFileNode).get("date","unknown");
    // etc, on sait mainteant que dans la liste des fichiers récement ouverts on a fileName à la date when. Bien sur à toi de stocker cette information dans les Preferences ;)
}
String preferedUITheme = applicationUserPreferences.get("preferedGUI","defaultTheme");

ce dernier exemple utilisera, sous windows, la base de registre et sous linux un fichier de configuration dans le user home directory.

[Caxton]

Effectivement ca ressemblerais à ce que je voudrais faire.

Toutefois je m'interroge quand aux risques de manipulation de la base de registre car je ne l'ai jamais utilisé directement.
-Quels sont les risques pour la stabilité des machines?
-Comment est-ce que fonctionne une base de registre ?
-Si j'ouvre par mégarde deux fois l'application, que se passera-t-il ?

En somme si cette solution me déduit car au moins elle a le mérite d'être solide, j'ai bien peur de plus m'y perdre que de passer par des fichier manipulable / dépannable.

[tchize_]

Effectivement ca ressemblerais à ce que je voudrais faire.

Toutefois je m'interroge quand aux risques de manipulation de la base de registre car je ne l'ai jamais utilisé directement.
-Quels sont les risques pour la stabilité des machines?

c'est juste des clés / valeurs hierarchisées, quelle risque tu pourrait encourir?

-Comment est-ce que fonctionne une base de registre ?

Vois la doc de windows, c'est un arbre central que toutes les applications utilisent pour stocker des informations (numéros de série, préférences utilisateur, historique, etc)

-Si j'ouvre par mégarde deux fois l'application, que se passera-t-il ?

La javadoc dit que le 'backingstore' ne sera pas corrompu, mais il ne donne pas de garantie supplémentaire sur la consistance des données de ton application. Si l'instance 1 écrit X=1, puis l'instance 2 écrit X=2,Y=2 et finalement l'instance 1 écrit Y=1, il y a fort a parier que le résultat final sera X=2,Y=1.


En somme si cette solution me déduit car au moins elle a le mérite d'être solide, j'ai bien peur de plus m'y perdre que de passer par des fichier manipulable / dépannable.[/QUOTE]

[Caxton]

Effectivement ca ressemble à un joyeux bazard
Restons simple. Une solution avec des fichiers manipulables que je peux réparé facilement me convient parfaitement.

[Caxton]

Bonjour,
Après un week end de repos, j'ai les idées bien plus clair.

J'ai tester la possibilité suivante qui a le mérite de correspondre à une partie de mes attentes :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
 
public static void main(String args[]) {
        java.awt.EventQueue.invokeLater(new Runnable() {
            public void run() {
                new Form1().setVisible(true);
 
                String urlAppli = new File(".").getAbsolutePath();
 
                JOptionPane.showMessageDialog(null, urlAppli , "Titre", JOptionPane.INFORMATION_MESSAGE);
 
            }
        });
    }

Ok urlAppli a bien D:\DevJava\TestWizard\.
Mais hélàs il fini par un "."
Y a-t-il une solution pour retirer ce point?

Merci

[tchize_]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

String urlAppli = new File("").getAbsolutePath();

qui retourne d'ailleurs la meme chose que System.getProperty("user.dir")

et qui, comme je l'ai déjà dit ne correspond pas toujours au répertoire où se trouve ton applcaition. Exemple je fait

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
cd c:\
java -jar d:\MonApplication\MonApplication.jar

user.dir vaudra "c:\"

[Caxton]

J'ai essayer dans le "." en mettant juste "" et ça fonctionne parfaitement.
Par contre je ne saurais dire ce qu'il en est de Linux.