Quali sono gli svantaggi del framework Java Swing GUI? [chiuso]

Ho usato Java Swing per alcune applicazioni desktop. Ma non ho usato così tanto altri framework GUI, quindi non posso confrontarli.

Ci sono sicuramente alcune cose che mi piacciono con Swing e altre che non mi piacciono, ma questa è la situazione con quasi tutto.

Quali sono i maggiori svantaggi del framework Java Swing GUI?

frameworks gui swing

— Jonas
fonte

La domanda è interessante. Anch'io mi chiedo quali siano i punti di forza e di debolezza di Swing, rispetto a QT, GTK, SWT, Winforms, Cocoa e simili. Forse dovresti riformulare il titolo per chiedere confronti , piuttosto che svantaggi (che tendono a portare risposte non ben argomentate)

— barjak

Risposte:

Devi avere Java installato da qualche parte. Questo vale ovviamente per tutti i framework GUI, ma Java ha la percezione di un gorilla da 2 tonnellate. È migliorato moltissimo, ma quei primi giorni di applet Java avevano spento molte persone. Se ne hai solo bisogno per eseguire la tua unica app, è un sacco di manutenzione per tenerlo aggiornato con patch di sicurezza e simili. Tutti devono avere Flash per YouTube, il framework .Net si installa dietro le quinte e tutti hanno javascript abilitato sul proprio browser. Java è di solito una cosa in più da fare.
Nonostante sia una sorta di scrittura una volta, corri ovunque, trovi ancora che Mac OSX non ha questa nuova cosa che vuoi usare o un client rifiuta di aggiornare il loro mandrake linux oltre JRE 1.4.
Come dev, devi pensare al threading. Ed è in un modo complicato, poiché il multi-threading è possibile ma lo swing finge che sia tutto a thread singolo. Ma poi metà delle biblioteche che prendi hanno un certo grado di multi-threading e presumi che tu sia a conoscenza di EDT invokeLater e forza molte lezioni nel modo più duro.
L'esperienza swing non si trasferisce facilmente ad altri tipi di sviluppo dell'interfaccia utente. Ad esempio, se sei un mago ai tavoli in .css, verrai completamente eliminato da Jtables, renderer, editor, ecc.

In generale, il problema principale con Swing è che non è stato all'altezza di come è stato commercializzato. È una tecnologia perfettamente adeguata per molti casi d'uso, ma quei primi 5 o 6 anni erano pieni di terribili implementazioni e applet atroci. E ora è una vecchia tecnologia: sul Web 3.0 o altro.

Detto questo, mi piace Swing e penso che i professionisti generalmente superino i contro quando hai bisogno di ciò che offre. Tuttavia l'esperienza web è così onnipresente ora che molti utenti passeranno un momento più facile con un'app Web rispetto all'app swing più snella e semplificata. E ci sono fantastiche app Swing là fuori, ma non sembrano essere mainstream.

— Steve Jackson
fonte

Sono nella stessa situazione dell'OP: conosco Swing e sono interessato a confrontarlo con altri takelit della GUI. Per me, i punti 1, 2 e 4 sono irrilevanti per la domanda. Quindi, vorrei reagire al punto 3: potresti fornire alcuni esempi di toolkit con interfaccia grafica multithread, per favore? Grazie.

— Barjak,

@barjak: la GUI multithread è un errore. L'unico che conosco è il vecchio Java AWT. Ma hanno imparato dagli errori quando hanno progettato Swing, che è single threaded come tutti i moderni framework GUI.

— Jonas,

@Jonas Far pensare a uno sviluppatore di multithreading è spesso un errore, ma non è possibile eseguire animazioni, effettuare chiamate RMI o eseguire calcoli intensi (questo è un toolkit client grasso, ricordate) senza un certo grado di multithreading.

— Steve Jackson,

@Steve: è vero. Ma si dovrebbe non fare chiamate RMI e calcoli intensi nella GUI-thread. Questo tipo di cose dovrebbe essere fatto in un thread in background, come in Swing e WPF.

— Jonas,

@barjak - Windows form, MFC, SWT, pyQT, Juce .... Sto facendo fatica a pensare a quelli che non sono multi-thread. Tuttavia, si applicano generalmente le stesse regole, non è possibile toccare i componenti della GUI se non dal thread che li ha creati.

— Steve Jackson,

Jonas,

Swing generalizza la tua architettura di base per offrirti un'esperienza utente neutrale sulla piattaforma. L'unico componente dei pesi massimi (fornito dal sistema operativo) è il contenitore JFrame e il resto è praticamente gestito da Swing. AWT, dall'altro lato, chiede al sistema operativo di disegnare tutti i suoi componenti dell'interfaccia utente, il che significa che è più veloce in molti modi poiché usi i componenti dell'interfaccia utente nativi specifici del sistema operativo. SWT cerca di raggiungere una via di mezzo, per vari componenti standard come pulsanti ed etichette (che sono disponibili sulla maggior parte dei sistemi operativi), consente al sistema operativo di gestirli e per altri componenti specializzati, SWT gestirà la creazione per te.

Detto questo, posso delineare gli svantaggi.

(1) Poiché il toolkit crea e rende i componenti per te piuttosto che chiedere al sistema operativo, non puoi trarre vantaggio dalla velocità dei componenti integrati forniti dal sistema operativo.

(2) L'interfaccia utente non è particolarmente interessante in quanto sembra estranea alla maggior parte delle piattaforme del sistema operativo per quanto riguarda l'aspetto e la sensazione che si utilizza.

(3) Alcuni gestori di layout, ad esempio GridBadLayout ecc., Potrebbero essere semplificati meglio. Ho perso il conto del numero di progetti su cui ho lavorato in cui le persone hanno racchiuso GridBagLayout in un codice su misura per ottenere un modo più semplice di usarlo.

Ti consiglierei di scrivere una semplice app in AWT, Swing e SWT e confrontare gli approcci di sviluppo con il prodotto finale tra tutti, quindi rivedere i vari commenti fatti da altri sviluppatori e decidere quale funziona meglio. Ho lavorato con Swing per molti anni e ho usato antipatia per SWT, ma mi sarei reso conto che Swing è molto più complicato di quanto debba essere rispetto ad altri framework là fuori.

— Pianeta Desolato
fonte

Swing è accelerato dalla GPU , i cui framework nativi non sono spesso frequenti, quindi in realtà penso che Swing sia più veloce. Questa è anche la strategia che WPF su Windows ha ma non WinForms (solo su alcune versioni di Windows). In che modo "[brutte] ... considerazioni su ciò che aspetto si utilizza" può essere vero quando è molto personalizzabile o è possibile utilizzare le piattaforme LaF? Sono d'accordo sul fatto che i gestori del layout sono davvero cattivi.

— Jonas,

Jonas, è l'aspetto "personalizzabile" dello swing che lo rende difficile rispetto ad altri framework. Se provi a sottrarti alle funzionalità offerte dal sistema operativo, perdi molti dei vantaggi che offre. La primissima versione di Swing è stata un incubo, che ha portato alla creazione di SWT in primo luogo. Successivamente Swing è stato migliorato per essere molto più veloce e hai classi come SwingUtilities che offrono un migliore supporto di threading per le GUI.

— Desolato pianeta,

Brutto potrebbe essere la parola sbagliata; alien potrebbe essere una parola migliore poiché look and feel non è esattamente lo stesso dell'interfaccia utente nativa, da quello che ricordo, hai Java, motivi, metal e pochi altri, ma in generale, non sono " È tutto così carino.

— Desolato pianeta,

La prossima cosa da guardare quando si fa un confronto è lo sforzo richiesto nello sviluppo di un'interfaccia utente. Non direi che i gestori del layout sono davvero pessimi, lì meglio di nessun layout (che devo affrontare nel lavoro su un dispositivo mobile), ma non fanno alcuno sforzo per semplificare il modello.

— Desolato pianeta,

Penso che in base a quello che hai detto, hai utilizzato la versione più recente di Swing, ma quando è uscito per la prima volta, le persone hanno avuto una forte antipatia per questo e ancora di più quando hanno cercato di fornire applet basate su Swing. C'è molta storia nei framework dell'interfaccia utente sviluppati in Java ed è una lettura interessante se lo guardi.

— Desolato pianeta,

-2

Lo swing è lento (cattive prestazioni), difficile / goffo da usare (rispetto a molti altri) e non sembra molto buono, anzi molto male, su alcune piattaforme.

— anto
fonte

Lo trovo veloce (ha accelerazione GPU, rispetto a molte GUI native) quindi non posso essere d'accordo con le prestazioni o hai qualche esempio? Come è difficile e goffo rispetto ad altri framework? Sono d'accordo che non sembra buono ma può essere configurato per apparire come app native o utilizzare un LaF personalizzato.

— Jonas,

Sembra più o meno sempre non nativo su GTK. Quello che ho sentito è che, poiché si basa su Java 2D per disegnare widget, è lento, ma non ho nulla per dimostrarlo. Sia Qt che GTK mi sembrano meno goffi, ma i gusti differiscono.

— Anto,

Ah, potrebbe funzionare peggio su alcune piattaforme. L'ho usato solo su Windows dove è GPU accelerato e molto veloce.

— Jonas,

La gente si lamenta ancora che qualcosa non sembra nativo, mentre usa sempre più cose del browser (pensa: stackexchange), dove ogni pagina ha un aspetto diverso? E velocità? Il più delle volte, un programma di interfaccia grafica interattiva attende l'utente.

— utente sconosciuto

La maggior parte dei programmi "alla moda" non sembrano più nativi. Swing non finisce meglio o peggio al riguardo. Le prestazioni della nostra app swing 50kloc (client fat) sembrano a posto. Molto più facile ottenere lo swing fino al punto di non andare in crash rispetto alle applicazioni "native".

— Tim Williscroft,