Effectivement je ne connaissais pas et le descriptif a l'air sympa.
Par contre en lisant le dernier post : http://www.developpez.net/forums/d78...t/#post4565792 c'est apparemment encore un proof of concept, même s'il est bien avancé. Ca n'a pas encore fait ces preuves mais il y a deux trois choses qui ont l'air prometteuse.
@pseudocode: pas sur de bien saisir en quoi l'indépendance à la plateforme est un inconvénient ? Des librairies comme JDIC qui implémentent le systray sont de bons exemples d'extensions pour profiter des possibilités des plateformes tout en restant générique.
Les avantages des uns sont les inconvénients des autres.
Le simple fait que des librairies comme cela existe montre bien qu'il y a un "manque" dans Swing. Ce manque est comblé en écrivant, au mieux des "wrappers", au pire des "émulateurs", de la toolkit native.
Ce qui est dommage, c'est que les toolkits natives évoluent beaucoup plus vite que ces librairies, sans parler des IDE pour dessiner les IHM.
SUN (et la communauté Java) a pris le parti d'implémenter sa propre toolkit afin de respecter sa philosophie de portabilité totale (Write once, run anywhere). C'est déjà un travail énorme de développer une toolkit, ca l'est encore plus de la faire évoluer pour qu'elle soit toujours à la pointe de la technologie. Aujourd'hui, Swing est un "follower'" qui a toujours du retard sur les innovations des autres toolkits, que ce soit en terme de composants, rendus ou langage.
La question "Devrait-on faire un client lourd en Java ?" se pose pour moi en d'autres termes:
"Pourquoi choisir Java pour développer un client lourd ?"
Les réponses sont variées (portabilité, frameworks disponibles, maitrise du langage, ...). Mais comme dans tout choix, il faut aussi de poser le problème des contraintes:
"Quelles sont les contraintes imposées par l'utilisation de Java POUR CE PROJET PARTICULIER ?"
Besoin d'une IHM qui déchire sous windows, peut-on utiliser Swing ? Besoin de portabilité, peut-on utiliser QtJambi ? Besoin de développer rapidement, a-t-on le temps de se former à Aerith ? Besoin de pérénité, peut-on prendre Eclipse E4 ?
Tout est dans la définition des contraintes du "client lourd".
ben, tu utilises les même mots dans les 2 cas...
(j'ai compris, tu as appliqué ton message utilisateur [ALGORITHME ...] au cas )
"Pourquoi choisir Java pour développer un client lourd ?", on peut voir le problème autrement...
Pourquoi apprendre plusieurs langages et maitriser plusieurs EDI quand on pourrait tout faire avec 1...
La valeur ajoutée est dans l'application, pas dans la techno...
Tu détournes un peu mon propos, mais d'un autre côté, je l'avais mal exprimé
J'essaye de faire mieux :
Outre les contraintes techniques qui justifieraient une plate-forme spécialisée, pourquoi avoir besoin de plusieurs langages et edi là où un couvre tous les besoins, la valeur ajouté est dans l'application, pas dans l'outil utilisé pour la concevoir
Pour moi, la techno (l'outil) est choisie en fonction des contraintes "projet" : compétences individuelles, répartitions des tâches, spécification du produit, délai/cout a respecter, ...
Je ne vois pas pourquoi Java serait la réponse universelle a tous les projets de client lourd. Ou au contraire un choix a éviter a tout prix. Tout dépend du projet.
Faire une IHM qui déchire en Swing, c'est aussi compliqué que vouloir faire une IHM portable en GTK. Autant choisir la techno en fonction des contraintes.
je pense que Sun doit vraiment bossé dur pour faire evoluer Swing car la je suis deja à mon deux ans que je bosse sur java et swing. le plus grand probleme est l'ergonomie de l'ihm car si on essai de le comparer aux ihm faites en .net, les ihm java son vraiment trop null. bien sur JavaFX est la pour remedier au probleme mais le developpement est toujours fatiguant car ca necessite de coder tous les composants à la main notament leur position et le look and feel (chose pas trop interessant).
le seul conseil que je peux proposé à Sun est que s'il veut aussi etre trop present au niveau application desktop, il doit faire evoluer rapidement JavaFx (du genre XAML/WPF du .net)
une question d'un mec qui ne code pas du tout de client lourd : les avancées graphiques d'android sont intégrables/reprenables pour un client lourd "java centric" ?
et merci bouye pour l'histoire de swing, c'était vraiment éclairant
quelques points en vrac :
- différences gui .Net/Java : .Net est très proche de D3D, là où java c'est nettement moins clair.
- à propos des layout : matisse ne résout il pas le souci joliment ?
++
Une autre question m'est venue à l'esprit à propos : j'ai souvent entendu/lu des plaintes à propos de l'EDT et de cette façon de gérer les traitements gourmands en ressources. Comment font les autres framework client lourd pour gérer la chose ?
Pourquoi pas clair ? Java étant multiplateforme il n'utilise D3d que sur windows.- différences gui .Net/Java : .Net est très proche de D3D, là où java c'est nettement moins clair.
Pour activer l'accélération direct3d sur windows tu peux même utiliser un paramétrage particulier :
-Dsun.java2d.d3d=true
j'utilise eclipse donc je ne m'étendrais pas trop la dessus, ne connaissant pas bien. Mais a ce que j'ai vu matisse ne sait pas gérer tout les layout (exemple formlayout de jgoodies)- à propos des layout : matisse ne résout il pas le souci joliment ?
Concernant l'EDT, le concept n'est pas critiqué en soi, on retrouve le même dans Qt il me semble d'ailleurs. C'est juste que, mal connu ou parfois mal exploité on trouve souvent de belles erreurs d'utilisation qui ont forgé une bonne réputation de lourdeur a Swing. Il faut bien manipuler le threading dans Swing, chose pas si maitrisé que ca par bcp de développeurs.
(android aucune idée, je ne connais pas le sujet.)
Sun ainsi que les publications des divers grandes maisons d'edition (O'Reilly, Addisson-Weisleym, etc. y compris les propres livres edites par Sun meme) sont principalement responsables de ce fait. Pendant longtemps, aucun de leur didacticiel, code ou livre ne se penchait ni n'insistait sur cela ni n'en expliquait l'importance crutiale et souvent la regle de l'EDT n'y etait meme pas respectee.
A partir de 2004~2005 dans les JavaOne, il a ete mentionne et annonce lors des JavaOne que des regles de bonnes conduites ainsi que la creation et l'adoption d'un Swing application framework et les guidelines qui allaient avec devaient etre rapidement mises en place pour eviter tout ce qui est de nos jours considere comme de la mauvaise programmation en Swing.
La plupart des livres recents edites par Sun semblent en tenir desormais compte, les demos fournies avec le JDK et les didacticiels semblent avoir ete corriges depuis (plus ou moins en silence) et en fouillant bien on peut meme trouver une ebauche de regles de bonnes conduites a suivre dans la doc disponible chez Sun. Si on en est arrive a ce point c'est surtout grace au martellage qu'on bien voulu faire Scott, Romain ou d'autres a l'epoque via leurs blogs ou leurs presentations lors de confs et dont nous nous sommes fait echo ici ou ailleurs. Mais globalement c'est quelques chose qu'ils nous faut regulierement remettre sur le tapis car je pense que pas mal de formateurs ou d'enseignants en lycee ou en fac ne se sont toujours pas mis au gout du jour.
Cote application framework, ben, c'est toujours dans les choux et les guidelines eux aussi sont portes disparus puisqu'ils devaient en decouler.
Je voulais surtout dire que Java était moins approprié pour faire de la 3D, pas que swing ne bénéficiait pas de D3D.
il y a myEclipse pour cela éventuellement, sachant que d'après ce que j'avais compris matisse venait surtout avec son propre layout qui aidait bien à la conception graphique de gui (drag and drop).
concernant l'EDT et la nécessité de gestion multithreadé, est ce aussi le cas pour du winforms/WPF ? Ou sous les gui mac ?
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Partager