Servez-vous - Commentaires

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - atout stepper

atout stepper — Mon, 04 Jun 2012 17:15:13 +0200

Meci pour l'article

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - theClimber

theClimber — Sun, 13 May 2012 15:31:57 +0200

Moi je suis pas d'accord, j'utilise pas Swing, mais SWT et c'est très joli... à la fois sur windows/linux/macosX ... c'est juste une question de librairie graphique.

Enfin bon, après faut évidement apprendre SWT : http://www.eclipse.org/swt/widgets/

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - dacrovinunghi

dacrovinunghi — Sat, 12 May 2012 13:57:16 +0200

@Edouard
Au fait j'ai un peu trollé désolé ^^

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - dacrovinunghi

dacrovinunghi — Sat, 12 May 2012 13:55:48 +0200

@Yoko
Je pense parei ldes langage de script niveau "latence" d'interface. Il ya une différence entre vm, moteur de script et appel compiler.
POur moi seul les langage compilés ou les moteur de scfript respectent l'os (atrribution de méméoire et gestion des processus).
@Edouard
Non la portabilité ca éloigne le dev du système et cela éloigne aussi du respect des normes de dev.

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - Yoko

Yoko — Tue, 08 May 2012 15:32:34 +0200

> Sans parler des latences, par ex. j'ai utilisé netbeans avec le jre 6, je me souviens très clairement que les menus déroulant mettaient une bonne seconde à s'afficher à l'époque.

Jamais vu ça, même sur mon netbook.

> je perdais tellement de temps que je finissais par sortir mes projets de l'ide pour terminer avec vim.

Ça dépend de tes besoins. Si tu veux éditer du texte oui c'est le top (je suis un fan de vim). Mais quand tu a a remanier du code (renommer des classes, des variables, réorganiser des arborescences en faisant suivre des références,...) je trouve que les 4s que prend netbeans pour analyser le code avant de t'ouvrir la boite de dialogue et les 2 ou 3s après que tu ai validé, sont bien plus court que la série d'édition/rebuild dont j'ai besoin pour le faire avec vim. De plus il est assez pratique de voir en même temps que tu tape ton code les erreurs/warnings checkstyle et/ou findbug. Ça permet d'éviter d'avoir une étape en plus à chaque fois erreur/correction (de plus l'information se trouve alors là où tu en a besoin et pas dans une autre fenêtre). La gestion des bases de données est elle aussi intéressante pour ne pas avoir à ouvrir un autre logiciel plus ou moins lourd pour y accéder et qui permet aussi de s'abstraire de la diversité des SGBD (tu garde la même interface que ce soit pour postgre, sqlite, mysql, oracle ou autre).

Bref chaque outils à ces qualités et ses défauts, il faut d'abord connaître ses besoins pour pouvoir faire un choix. De plus les IDE Java sont généralement très configurables c'est dommage de ne pas passer un peu de temps pour aller voir si on ne peux pas arranger ce qui nous bloque (par exemple eclipse est désagréable si on laisse la compilation à la sauvegarde)).

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - plop

plop — Tue, 08 May 2012 15:30:42 +0200

Les screenchiottes sont hideux.
C'est peut-être parce que c'est sur Mac, qui pousse les dégradés et les ombres à un point vomitif, mais on dirait que ça va être moche ailleurs aussi.

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - Edouard

Edouard — Tue, 08 May 2012 14:54:45 +0200

Mon propos est simplement de montrer qu'en utilisant le look and feel de l'OS hôte, on s'affranchit déjà de l'aspect "moche" du look and feel Metal, c'est tout.

@SQP: titre modifié pour moins d’ambiguïté

@dacrovinunghi: quel est le rapport ? Dans certain cas cela vaut le coup de sacrifier quelques ressources pour une VRAIE portabilité, simple question de compromis

@jean: les look and feel que tu vois sont ceux du système hôte (Mac, Windows...) justement le développeur n'est pas responsable de cette apparence (forme de bouton, style des barres, etc..)

@Rotnem: j'ai mis un screen mac + un linux, c'est plus clair ?

@2go: tu veux dire l'assistant de création d'interface de Netbeans ? Cela ne changera pas le problème du look and feel final

@Yoko: je partage ton point de vue

@f0xarch: je parle ici bien de java pour application "standalone" et non pas pour faire tourner sur un serveur d'application tomcat.

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - f0xarch

f0xarch — Tue, 08 May 2012 14:48:51 +0200

Nassim, en tant que sysadmin, j'évite aussi. J'ai une appli qui tourne sur du tomcat qui a besoin d'un serveur dédié, 10Go de ram utilisé en repos. gg

Je pense connaître un peu swing, et aux dernière nouvelles, depuis le jdk7, j'arrive plus à utiliser le look and feel gtk pour linux. Sinon swing est encore une surcouche aux traditionnels toolkit, qui eux même ont des surcouches pour s'intégrer partout.

Par exemple sous linux, quand tu utilises swing, tu vas utiliser le LAF gtk + gtk-engines-qt pour l'intégrer à kde. Ca commence à devenir _ultra_ lourd, et le rendu est très loin d'être parfait... Ca donne surtout une grosse impression d'interface brouillonne.
Sans parler des latences, par ex. j'ai utilisé netbeans avec le jre 6, je me souviens très clairement que les menus déroulant mettaient une bonne seconde à s'afficher à l'époque. C'est pas ce que j'appelle acceptable. A chaque fois que j'ai voulu passer à Eclipse et netbeans (dernière fois il y a 2 ans), je perdais tellement de temps que je finissais par sortir mes projets de l'ide pour terminer avec vim.

Alors, oui, c'est pas la fin du monde au niveau fonctionnel, mais à la fin, l'utilisateur choisira son application, et si celles en java sont moches et lentes, ce sera vite plié...

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - Yoko

Yoko — Tue, 08 May 2012 14:20:25 +0200

@dacrovinunghi
> Le byte code qui appele la biblio graphique qui appelle les fonctions systèmes...

C'est identique pour les langages de scripts comme python, perl ou ruby et les langages compilés ne font qu'alléger l'appel code -> bibliographique. En C++/Qt, tu as ton code qui appelle Qt, qui appel la xlib, qui appel XCB (oui la xlib utilise maintenant XCB pour gagner un peu en vitesse) qui effectue les appels systèmes. Bref décrire la chaîne d'exécution sans en dire plus ce n'est pas une argumentation valide (sinon on pourrais dire qu'un appel système en lui même c'est déjà très lourd par exemple).

Si vraiment avoir autant de maillons te gène, il faut regarder du coté de directfb est arrêter d'utiliser xorg/xlib : https://linuxfr.org/news/demonstrat...

Très franchement je ne trouve pas java lent, au démarrage un peu, mais je ne démarre pas mes application toutes les minutes donc ça ne me gène pas. Il manque peut être un peu de réactivité (ce qui n'a rien avoir avec la vitesse soit dit en passant), mais je ne remettrais pas en cause le langage pour ça. Firefox manque de réactivité et est écris en C++.

Enfin pour les interfaces graphiques. Je ne vois pas ce qui empêche de re faire avec swing, l'interface de VLC (c'est pas à pleurer de beauté, mais à quoi ça sert d'avoir une interface tellement belle qu'elle devraient être au Louvre ?).

Je me pose plus de question sur l'intégration (avoir un sélecteur de fichier identique à ce qu'on trouve sur la plateforme, avoir une barre de défilement qui se comporte de la même façon etc) et sur le dynamisme de swing (ce serait cool d'avoir des widgets en plus).

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - Guillaume

Guillaume — Tue, 08 May 2012 13:58:38 +0200

Quand je fais des interfaces en Java, je n'utilise pas Swing/AWT (y'a des bindings QT et GTK qui existent, God bless them). Il y a tout un tas de commentaires et pas qu'ici qui dit Java c'est lourd etc... Préparez vous au JDK8 vous allez être surpris (faites une petite recherche en utilisant "java project jigsaw")

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - 2go !

2go ! — Tue, 08 May 2012 10:40:27 +0200

Comme le dis Jean, c'est juste... moche ! Difficile de faire de belles interfaces avec Java, j'ai pas creusé la question mais la seule valable (mais pas la meilleure) c'est de passer par NetBeans. Le problème c'est que l'on perd en portabilité !

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - Rotnem

Rotnem — Tue, 08 May 2012 10:40:10 +0200

Je ne suis pas fan non plus!
Sur Mac les interfaces graphiques sont particulièrement soignées par les développeurs (en général)! Il aurait fallu montrer ce screenshot sous windows ça serait mieux passé :P

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - Nassim

Nassim — Tue, 08 May 2012 10:37:55 +0200

Je rejoins les autres commentaires en disant que même les interfaces présentées sont moches.
Mais ce que je reproche le plus autant que sysadmin à Java est sa lourdeur extrême (accompagnée d'une consommation hallucinante en ressources).

En tout cas, sous GNU/Linux, j'évite au maximum ce langage.

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - jean

jean — Tue, 08 May 2012 10:08:16 +0200

Heu... je trouve que les screenshots sont justement moches.

Ce n'est pas la faute de java, c'est la faute du graphiste qui a choisi ce look and feel. Bref, en gros c'est souvent la faute du développeur qui a mauvais goût.

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - dacrovinunghi

dacrovinunghi — Tue, 08 May 2012 08:27:32 +0200

C'est surtout d'une lourdeur... Et peu importe la puissance de la machine.
Le byte code qui appele la biblio graphique qui appelle les fonctions systèmes...

"Les interfaces graphiques en java sont forcémment moches" -> FAUX ! - SQP

SQP — Tue, 08 May 2012 07:19:53 +0200

"Les interfaces graphiques en java sont moches" -> VRAI, mais ça pourrait ne pas forcément être le cas !

et pour la lenteur t'as un autre patch magique ?

Une version 2.0 sur les rails - Cherche beta testeurs - ersatz

ersatz — Sat, 07 Jan 2012 19:10:09 +0100

Il manque les screenshots dans le site edouard ! L'exe fonctionne impec.

Tutoriel d'utilisation de java web start - papus

papus — Fri, 10 Jun 2011 10:36:24 +0200

merci bcp pour votre aide et pour votre tuto

finalement ça marche bien sur mon environnement de dev

Tutoriel d'utilisation de java web start - Edouard

Edouard — Thu, 09 Jun 2011 18:02:38 +0200

C'est normal ! Il faut autosigner l'archive jar, et l'explication est ici: http://www.inouire.net/blog/index.php?post/2010/03/26/Signer-simplement-une-archive-jar

Si c'est pas bien fait, ça

Tutoriel d'utilisation de java web start - papus

papus — Thu, 09 Jun 2011 15:27:43 +0200

j'ai trouvé finalement le repertoire où mettre le jar.
mon erreur etait de le copier dans le projet web avant de compacter en war. du coup lors du deploiement le jar n'est pas copié.

en mettant cette fois la ressource, j'arrive à telecharger le jar.

ça ne marche pas encore mais c'est juste un probleme de signature du fichier jar : voice l'erreur :

Une erreur est survenue au cours du lancement ou de l'exécution de l'application.

Titre : Test JWS
Fournisseur : ca-cib.com
Catégorie : Erreur de sécurité

Une application non signée demande un accès illimité au système
Ressource non signée : http://localhost:port/Projetweb/app...