lancer une JVM à partir d'une JVM

Version imprimable

comment lancer une JVM supportant AWT/Swing à partir de java (donc d'une jvm)

je pensais à :
Code:

1 2 Process proc = shell.exec("java osteo.Run",envp,dir);
mais ca retourne :
Code:

1 2 3 4 5 6 7 8 9 10 Exception in thread "main" java.awt.HeadlessException: No X11 DISPLAY variable was set, but this program performed an operation which requires it. at java.awt.GraphicsEnvironment.checkHeadless(GraphicsEnvironment.java:159) at java.awt.Window.<init>(Window.java:317) at java.awt.Frame.<init>(Frame.java:419) at java.awt.Frame.<init>(Frame.java:384) at javax.swing.JFrame.<init>(JFrame.java:150) at osteo.Run.<init>(Run.java:45) at osteo.Run.main(Run.java:133)
sachant que Run.java:133 correspondant a l'initialisation d'une JFrame.

je sais qu'Ant sait le fare (avec des fork je pense), mais j'ai rien trouvé de concret

17/05/2006, 17h33
kevredon

il faut reprendre TOUTES les variables de System.getenv() pour envp (mis dans exec())
17/05/2006, 17h40
adiGuba

Salut,

Ou bien tout simplement mettre null à la place de envp, comme c'est indiqué dans la doc : http://javasearch.developpez.com/j2s...va.lang.String[],%20java.lang.String[],%20java.io.File)

Code:

Process proc = shell.exec("java osteo.Run",null,dir);

a++
18/05/2006, 11h15
kevredon

si je créé un envp est que j'execute une JVM à partir d'une autre c'est parce que j'ai besoin de mettre des variables d'environnement supplementaire (pour la JNI ainsi que des jar externes), donc il ne faut pas mettre null (nous savons tous lire la doc avant de poster (enfin j'espere)), mais les recopier et ajouter les nouvelles
18/05/2006, 11h21
adiGuba

Citation:

Envoyé par kevredon

si je créé un envp est que j'execute une JVM à partir d'une autre c'est parce que j'ai besoin de mettre des variables d'environnement supplementaire (pour la JNI ainsi que des jar externes), donc il ne faut pas mettre null (...), mais les recopier et ajouter les nouvelles

Ok pas de soucis là dessus...

Citation:

Envoyé par kevredon

(nous savons tous lire la doc avant de poster (enfin j'espere))

Justement : non :aie:
C'est fou le nombre de question qui trouvent leur réponse directement dans la doc. de la méthode qui pose problème... alors je préfère prévenir... ;)

A noter également qu'avant Java 5.0 getenv() est deprecated...

a++
18/05/2006, 11h33
kevredon

c'est vraiment sympa que les modo interviennent souvent (bon boulot)

Citation:

A noter également qu'avant Java 5.0 getenv() est deprecated...

qui utilise encore une java < 5.0 :roll: (passons vite à la 6.0, un peu moins portable, mais plus puissante) à pars J2EE (et encore, c'est relativement compatible)
18/05/2006, 11h41
adiGuba

Citation:

Envoyé par kevredon

c'est vraiment sympa que les modo interviennent souvent (bon boulot)

Ben les modos sont avant tout des membres réguliers du forum ;)

Citation:

Envoyé par kevredon

qui utilise encore une java < 5.0

Beaucoup de monde malheureusement... surtout en entreprise...

Citation:

Envoyé par kevredon

(passons vite à la 6.0, un peu moins portable, mais plus puissante)

Oui vivement la 6.0 qui promet de plus en plus... mais je ne vois pas en quoi elle sera moins portable !?

a++
18/05/2006, 11h58
kevredon

je ne trouve plus l'article sur la portabilite mais ca porte essentiellement sur la partie graphique.
On sait que java a un peu de mal avec KDE (ne parlons meme pas de GTK) (avec les L&F par exemple).
Java 6 va permettre d'utiliser plus d'environements graphiques, et surtout plus de leurs widgets (ex : systray icon), mais en contrepartie il faudra verifier ( isXXX() ) si cette fonction graphique existe dans l'environement d'execution graphique.

C'est de memoire, les autres points sont des souvenirs flous.
M'enfin il existe toujours SWT, et vu que j'utilise que ca, j'aurais pas de soucis
18/05/2006, 12h31
adiGuba
Citation:

Envoyé par kevredon

On sait que java a un peu de mal avec KDE (ne parlons meme pas de GTK) (avec les L&F par exemple).

Justement il me semble que Java 6 améliore grandement le LookAndFeel système, que ce soit sous Linux avec KDE et Gnome, et même sous Windows où il est encore plus proche du vrai look du système (ce n'est plus un LnF similaire, mais un LnF qui utilise le style du système).

Citation:

Envoyé par kevredon

Java 6 va permettre d'utiliser plus d'environements graphiques, et surtout plus de leurs widgets (ex : systray icon), mais en contrepartie il faudra verifier ( isXXX() ) si cette fonction graphique existe dans l'environement d'execution graphique.

Il s'agit des classes SystemTray et Desktop qui premettent respectivemment d'ajouter une icone dans la zone de notification, et d'utiliser les associations de fichiers et le navigateur/client mail par défaut.

Ces fonctionnalitées pouvant être très différentes (voir absente) d'un système à l'autre (et même d'un WindowManager à l'autre pour Linux), il existe une certain nombre de méthode isXXXSupported() pour vérifier si la fonctionnalité est supportée ou pas, afin d'utiliser une solution alternative le cas échéant...

Du coup c'est sûr que le programme pourra être différent d'un système à l'autre, mais on garde quand même la portablilité... Les méthodes isXXXXSupported() permettront simplement de mettre en place des solutions alternatives dans le cas où la fonctionnalité n'est pas supportée...

C'est vrai que ce principe est assez nouveau dans l'API standard, où chaque méthode était garantit, mais cela permettra surement une meilleure intégration, et facilitera certaine action toutes simples, qui était autrefois assez complexe à mettre en place (et souvent encore moins portable).

Citation:

Envoyé par kevredon

M'enfin il existe toujours SWT, et vu que j'utilise que ca, j'aurais pas de soucis

A noter que ce "problème" (pour moi ce n'en est pas vraiment un) existe également pour SWT. Par exemple la méthode Display.getSystemTray() de SWT renvoit null si aucun SystemTray n'est disponible...

Dans un cas on traite une valeur null, et dans l'autre on vérifie avant la valeur d'un booleen... Pour moi cela revient au même et le code est assez similaire :

Avec SWT :
Code:

1 2 3 4 5 6 Tray systemTray = Display.getSystemTray (); if (systemTray!=null) { // Utilisation du système tray } else { // Solution altenative }
Code:

1 2 3 4 5 6 if (SystemTray.isSupported()) { SystemTray = SystemTray.getSystemTray(); // Utilisation du système tray } else { // Solution altenative }
Ce "problème de portabilité" est plus un problème de "philosophie", car il implique qu'un programme Java puissent fonctionner différemment d'une machine à l'autre... mais cela est vraiment neccessaire pour mieux intégrer les applications Desktop au bureau de l'utilisateur...

a++

PS : désolé, je viens de voir que j'ai fait un méchant pavé :aie:
18/05/2006, 12h37
moritan

Citation:

Envoyé par adiGuba

PS : désolé, je viens de voir que j'ai fait un méchant pavé :aie:

Sauf que des pavé comme çà ça faire plaisir, on pourrait presque imaginé un tutoriel ou en article made in adiGuba...;)
18/05/2006, 12h49
kevredon

c'est à ça que je pensais, maintenant que j'ai lu je me rapelle.
Voila, tout est clair maintenant :P, merci pour ce "cours" (pour de vrai).

Par contre tu m'a appris qqchose, java 6 utilisera les widgets ? c'est serieux ? plus de swing lourd ? plus de SWT pas pratique ?
Si c'est le cas alors je devellope directement avec java 6 (les entreprises n'ont qu'a se plier à ma solutions :aie: ).
18/05/2006, 13h24
adiGuba

Citation:

Envoyé par kevredon

Par contre tu m'a appris qqchose, java 6 utilisera les widgets ? c'est serieux ? plus de swing lourd ? plus de SWT pas pratique ?

Techniquement je ne sais pas exactement comment cela fonctionne, mais je sais que Java 6 va apporter une meilleure fidélité au lookandfeel système (lorsqu'on utilise le Lnf système bien sûr). Les LnFs GTK et Windows (pour KDE/Qt je n'en sais rien) on été particulièrement retouché afin d'utiliser plus ou moins directement les éléments natifs...

Cf : Desktop Java Features in Mustang et Java SE 6 Release Notes
18/05/2006, 15h03
sinok

Pour KDE/Qt il n'y a rien au niveau L&F chez sun, pour linux c'est du L&F gtk point barre,
Par il existe un projet de L&F GPL utilisant nativement QT et qui sera donc en GPL et destiné aux utilisateurs finaux. Il permetra comme le L&F windows de faire varier la tête de l'application selon le thème utilisé par KF, mais bon pour l'instant ça reste un peu moche car de loin pas en fin de développement.