>Moi oui, et sincèrement, SWING c'est de la daube.
Bon ça c'est ton expérience perso. Ce qui est sûr c'est que SWING c'est pas la partie de la plateforme JAVA qui jouit de la meilleure réputation. ..
Je pense simplement que c'est un bon choix aujourd'hui pour développer une application de gestion (non temps réel) en entreprise dans un environnement hétérogène.
En fait, non pas pour SWING lui même, qui produit aujourd'hui des interfaces multi-OS "potables", sans exiger trop de connaissances bas niveau mais surtout pour avoir accès à la richesse des librairies JAVA. Quand ton GUI doit s'intégrer à des systèmes tiers avec RMI , JDBC ( SGBDR), JCA ( connecteurs vers mainframes), JNDI ( LDAP, DNS), etc. La plateforme Java J2SE+J2EE est riche et c'est un gain de temps appréciable que de pouvoir s'affranchir de considérations systèmes que tu dois gérer un C. Et ceci sans pour autant trop te limiter: si tu veux faire appel à des API natives en C/C++ tu peux toujours le faire avec JNI.
Pour en revenir, au débat, le futur XUL ou XAML/Avalon visent tout à fait ce public là: les développeurs de GUI d'entreprise ( à la VB). Pour générer rapidement des clients lourds plus riches en fonctionnalités que des clients légers et presqu'aussi "simplement". A mon sens que "le futur concurrent de XAML" ne supporte pas le Java c'est se priver d'une plateforme complète pour développer ce type d'applications fusse-t-elle propriétaire ( mais concurrente de DotNet).
[^] # Re: Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn
Posté par bengali . En réponse à la dépêche Mozilla souhaite s'allier à d'autres projet Libres pour faire face à MS-Longhorn. Évalué à 1.
Bon ça c'est ton expérience perso. Ce qui est sûr c'est que SWING c'est pas la partie de la plateforme JAVA qui jouit de la meilleure réputation. ..
Je pense simplement que c'est un bon choix aujourd'hui pour développer une application de gestion (non temps réel) en entreprise dans un environnement hétérogène.
En fait, non pas pour SWING lui même, qui produit aujourd'hui des interfaces multi-OS "potables", sans exiger trop de connaissances bas niveau mais surtout pour avoir accès à la richesse des librairies JAVA. Quand ton GUI doit s'intégrer à des systèmes tiers avec RMI , JDBC ( SGBDR), JCA ( connecteurs vers mainframes), JNDI ( LDAP, DNS), etc. La plateforme Java J2SE+J2EE est riche et c'est un gain de temps appréciable que de pouvoir s'affranchir de considérations systèmes que tu dois gérer un C. Et ceci sans pour autant trop te limiter: si tu veux faire appel à des API natives en C/C++ tu peux toujours le faire avec JNI.
Pour en revenir, au débat, le futur XUL ou XAML/Avalon visent tout à fait ce public là: les développeurs de GUI d'entreprise ( à la VB). Pour générer rapidement des clients lourds plus riches en fonctionnalités que des clients légers et presqu'aussi "simplement". A mon sens que "le futur concurrent de XAML" ne supporte pas le Java c'est se priver d'une plateforme complète pour développer ce type d'applications fusse-t-elle propriétaire ( mais concurrente de DotNet).