Quels sont les inconvénients du framework GUI Java Swing? [fermé]

11

J'ai utilisé Java Swing pour certaines applications de bureau. Mais je n'ai pas beaucoup utilisé d'autres frameworks GUI donc je ne peux pas les comparer.

Il y a certainement des choses que j'aime avec Swing et d'autres que je n'aime pas, mais c'est la situation avec presque tout.

Quels sont les plus gros inconvénients du framework Java Swing GUI?

frameworks gui swing Jonas
la source
2
La question est intéressante. Je me demande aussi quelles sont les forces et les faiblesses de Swing, par rapport à QT, GTK, SWT, Winforms, Cocoa, etc. Vous devriez peut-être reformuler le titre pour demander des comparaisons , plutôt que des inconvénients (qui ont tendance à apporter des réponses peu argumentées)
barjak

Réponses:

3

  1. Vous devez avoir installé java quelque part. C'est vrai pour tous les frameworks GUI bien sûr, mais java a la perception d'un gorille de 2 tonnes. Les choses se sont améliorées, mais ces premiers jours avec les applets Java ont découragé beaucoup de gens. Si vous n'en avez besoin que pour exécuter votre seule application, il faut beaucoup de maintenance pour la maintenir à jour avec les correctifs de sécurité et autres. Tout le monde doit avoir Flash pour youtube, le framework .Net s'installe en coulisses et tout le monde a activé javascript sur son navigateur. Java est généralement une chose supplémentaire à faire.

  2. Bien que ce soit en quelque sorte à écriture unique, exécuté n'importe où, vous trouvez toujours que Mac OSX n'a ​​pas cette nouveauté que vous souhaitez utiliser ou qu'un client refuse de mettre à niveau sa mandrake linux après JRE 1.4.

  3. En tant que développeur, vous devez penser au filetage. Et c'est d'une manière délicate, car le multi-threading est possible mais le swing prétend que tout est simple. Mais alors la moitié des bibliothèques que vous tirez ont un certain degré de multi-thread et supposent que vous connaissez EDT invokeLater et cela force beaucoup de leçons à la dure.

  4. L'expérience Swing ne se transfère pas facilement à d'autres types de développement d'interface utilisateur. Par exemple, si vous êtes un expert des tables en .css, vous allez être complètement guidé par Jtables, les rendus, les éditeurs, etc.

En général, le principal problème avec Swing est qu'il ne correspondait pas à la façon dont il était commercialisé. C'est une technologie parfaitement adaptée à de nombreux cas d'utilisation, mais ces 5 ou 6 premières années étaient pleines d'implémentations horribles et d'applets atroces. Et maintenant, c'est de la vieille technologie - sur le Web 3.0 ou autre.

Cela dit, j'aime Swing et je pense que les avantages l'emportent généralement sur les inconvénients lorsque vous avez besoin de ce qu'il offre. Cependant, l'expérience Web est tellement omniprésente maintenant que de nombreux utilisateurs auront plus de facilité avec une application Web que l'application swing étonnante la plus rationalisée. Et il existe de superbes applications Swing, mais elles ne semblent pas être courantes.

Steve Jackson
la source
1
Je suis dans la même situation que l'OP: je connais Swing et je suis intéressé à le comparer à d'autres prises de vue GUI. Pour moi, les points 1, 2 et 4 sont sans rapport avec la question. Donc, je voudrais réagir au point 3: pourriez-vous donner quelques exemples de boîtes à outils GUI multithread, s'il vous plaît? Merci.
barjak
2
@barjak: L'interface graphique multithread est une erreur. Le seul que je connaisse est l'ancien Java AWT. Mais ils ont appris des erreurs lors de la conception de Swing, qui est monothread comme tous les frameworks GUI modernes.
Jonas
@Jonas Faire réfléchir un développeur sur le multithreading est souvent une erreur, mais vous ne pouvez pas exécuter d'animations, effectuer des appels RMI ou effectuer des calculs intenses (il s'agit d'une boîte à outils pour gros clients, rappelez-vous) sans un certain degré de multithreading.
Steve Jackson
3
@Steve: C'est vrai. Mais vous ne devriez pas faire d'appels RMI ni de calculs intenses dans le thread GUI. Ce genre de choses devrait être fait dans un thread d'arrière-plan, comme dans Swing et WPF.
Jonas
@barjak - Windows Forms, MFC, SWT, pyQT, Juce .... J'ai plus de mal à penser à ceux qui ne sont pas multi-thread. Les mêmes règles s'appliquent généralement cependant, vous ne pouvez pas toucher vos composants GUI, sauf à partir du thread qui les a créés.
Steve Jackson
2

Jonas,

Swing généralise votre architecture sous-jacente pour vous offrir une expérience utilisateur neutre sur la plateforme. Le seul composant lourd (fourni par le système d'exploitation) est le conteneur JFrame et le reste est à peu près géré par le Swing takeit. AWT de l'autre côté, demande au système d'exploitation de dessiner tous ses composants d'interface utilisateur, ce qui signifie qu'il est plus rapide à bien des égards que votre utilisation des composants d'interface utilisateur natifs spécifiques au système d'exploitation. SWT essaie de trouver un terrain d'entente, pour divers composants standard comme les boutons et les étiquettes (qui sont disponibles sur la plupart des systèmes d'exploitation), il permet au système d'exploitation de les gérer et pour d'autres composants spécialisés, SWT se chargera de la création pour vous.

Cela dit, je peux souligner les inconvénients.

(1) Étant donné que la boîte à outils crée et rend les composants pour vous plutôt que de demander au système d'exploitation, vous ne bénéficiez pas de la vitesse des composants intégrés fournis par le système d'exploitation.

(2) L'interface utilisateur n'est pas particulièrement attrayante car elle semble étrangère à la plupart des plates-formes de système d'exploitation en ce qui concerne l'apparence que vous utilisez.

(3) Certains des gestionnaires de mise en page, à savoir GridBadLayout, etc. pourraient être mieux simplifiés. J'ai perdu le compte du nombre de projets sur lesquels j'ai travaillé où les gens ont encapsulé le GridBagLayout dans du code sur mesure pour obtenir un moyen plus simple de l'utiliser.

Je vous conseille d'écrire une application simple en AWT, Swing et SWT et de comparer les approches de développement et le produit final entre elles, puis de passer en revue les divers commentaires faits par d'autres développeurs et de décider laquelle fonctionne le mieux. J'ai travaillé avec Swing pendant de nombreuses années et j'ai utilisé le SWT que je n'aime pas, mais je me suis rendu compte que Swing est beaucoup plus compliqué qu'il ne devrait l'être par rapport à d'autres frameworks.

Planète désolée
la source
4
Swing est accéléré par GPU , ce qui n'est pas souvent le cas des frameworks natifs, donc je pense que Swing est plus rapide. C'est également la stratégie de WPF sur Windows mais pas de WinForms (uniquement sur certaines versions de Windows). Comment "[moche] ... en ce qui concerne l'apparence que vous utilisez" peut-il être vrai quand il est très personnalisable ou que vous pouvez utiliser les plates-formes propres à LaF? Je suis d'accord que les gestionnaires de mise en page sont vraiment mauvais.
Jonas
Jonas, c'est l'aspect "personnalisable" du swing qui le rend difficile par rapport aux autres frameworks. Si vous essayez de vous éloigner des fonctionnalités que le système d'exploitation vous offre, vous perdez de nombreux avantages qu'il offre. La toute première version de Swing était un cauchemar, ce qui a conduit à la création de SWT en premier lieu. Plus tard, Swing a été amélioré pour être beaucoup plus rapide et vous avez des classes comme SwingUtilities qui offrent une meilleure prise en charge des threads pour les interfaces graphiques.
Desolate Planet
Laid peut être le mauvais mot; extraterrestre pourrait être un meilleur mot car l'apparence n'est pas exactement la même que l'apparence de l'interface utilisateur native, d'après ce dont je me souviens, vous avez Java, le motif, le métal et quelques autres, mais en général, ils ne sont pas ' t tout ce joli.
Desolate Planet
La prochaine chose à regarder lors d'une comparaison est l'effort impliqué dans le développement d'une interface utilisateur. Je ne dirais pas que les gestionnaires de disposition sont vraiment mauvais, il vaut mieux que pas de disposition du tout (que je dois gérer dans le travail sur un appareil mobile), mais ils ne font aucun effort pour simplifier le modèle.
Desolate Planet
Je pense que sur la base de ce que vous avez dit, vous avez utilisé la version la plus récente de Swing, mais quand elle est sortie, les gens l'ont beaucoup détestée et encore plus quand ils ont essayé de fournir des applets basées sur Swing. Il y a beaucoup d'histoire dans les frameworks d'interface utilisateur développés en Java et c'est une lecture intéressante si vous y regardez.
Desolate Planet
-2

Le swing est lent (mauvaise performance), difficile / maladroit à utiliser (par rapport à beaucoup d'autres) et il ne semble pas très bon, en fait très mauvais, sur certaines plates-formes.

Anto
la source
5
Je le trouve rapide (il a une accélération GPU, par rapport à de nombreuses interfaces graphiques natives), donc je ne suis pas d'accord avec les performances ou avez-vous des exemples? En quoi est-il difficile et maladroit par rapport à d'autres cadres? Je suis d'accord qu'il ne semble pas bon, mais il peut être configuré pour ressembler à des applications natives ou utiliser un LaF personnalisé.
Jonas
Il semble plus ou moins toujours non natif sur GTK. Ce que j'ai entendu, c'est que parce qu'il s'appuie sur Java 2D pour dessiner des widgets, c'est lent, mais je n'ai rien à prouver. Qt et GTK me semblent moins maladroits, mais les goûts diffèrent.
Anto
Ah, cela peut être pire sur certaines plates-formes. Je ne l'ai utilisé que sur Windows où il est accéléré par le GPU et très rapide.
Jonas
6
Les gens se plaignent toujours que quelque chose ne semble pas natif, tout en utilisant de plus en plus de choses de navigateur (pensez: stackexchange), où chaque page est différente? Et la vitesse? La plupart du temps, un programme GUI interactif attend l'utilisateur.
utilisateur inconnu
2
La plupart des programmes "à la mode" ne semblent plus natifs. Le swing ne finit ni mieux ni pire à cet égard. Les performances de notre application swing 50kloc (gros client) semblent correctes. Il est beaucoup plus facile de basculer au point de ne pas planter que les applications "natives".
Tim Williscroft