Discussion :

[kevredon]

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

je pensais à :

Code :

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

1
2
 
Process proc = shell.exec("java osteo.Run",envp,dir);

mais ca retourne :

Code :

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

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

[kevredon]

il faut reprendre TOUTES les variables de System.getenv() pour envp (mis dans exec())

[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 :

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

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

a++

[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

[adiGuba]

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...

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

Justement : non
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++

[kevredon]

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

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

qui utilise encore une java < 5.0 (passons vite à la 6.0, un peu moins portable, mais plus puissante) à pars J2EE (et encore, c'est relativement compatible)

[adiGuba]

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

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

qui utilise encore une java < 5.0

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

(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++

[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

[adiGuba]

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).

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).

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 :

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

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

Code :

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

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é

[moritan]

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

Sauf que des pavé comme çà ça faire plaisir, on pourrait presque imaginé un tutoriel ou en article made in adiGuba...

[kevredon]

c'est à ça que je pensais, maintenant que j'ai lu je me rapelle.
Voila, tout est clair maintenant , 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 ).

[adiGuba]

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

[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.