Inizi a migrare il tuo progetto Swing su JavaFX [chiuso]

Ho un progetto di 4 anni scritto in Swing + SwingX. Attualmente, è ancora vivo e vegeto.

Tuttavia, man mano che arrivano altre richieste di funzionalità correlate alla GUI (ad esempio, una tabella ad albero ordinabile), comincio a sentire la difficoltà nel completare le richieste. Questo è vero soprattutto perché non c'è alcuno sviluppo attivo attorno al progetto SwingX.

Inoltre, difficilmente riesco a trovare alcun framework Java GUI valido, ma mantenuto attivamente / sviluppato / in evoluzione.

Mi chiedevo, qualcuno degli sviluppatori Swing sente la stessa cosa? Hai iniziato a migrare il tuo progetto Swing in un framework GUI sviluppato molto più attivo, come JavaFX?

Sto passando personalmente a JavaFX (2.1+, non alla vecchia strana versione 1.x con il brutto linguaggio di scripting). Il nuovo JavaFX non è perfetto al 100%, ma è già uno spettacolo dannatamente più piacevole da usare rispetto a Swing, vedo un futuro ragionevole per questo (soprattutto dato il motore Webkit incorporato).

Mi chiedo spesso la stessa cosa, ma non credo che migrerei i progetti esistenti su JavaFX. Almeno non per ora, e non per progetti di medie e grandi dimensioni. Vorrei, tuttavia, prendere in considerazione JavaFX per nuovi progetti e prendere in considerazione una migrazione in futuro e rivalutare la domanda in base ai progressi di JavaFX.

Al momento, le mie preoccupazioni sono:

• Immaturità

  Sì, andremo presto alla 3.0, ma non è in circolazione da così tanto tempo e ha ancora subito importanti cambiamenti. Quindi, per i software aziendali di grandi dimensioni e avversi al rischio, questo è un punto relativamente doloroso.

• Prestazione

  Non ho visto abbastanza dati concreti sulle differenze di prestazioni.

• Widget e componenti

  Non ho visto abbastanza guadagno nei nuovi componenti. Questo può riguardare l'immaturità, immagino. Inoltre non so ancora quanto possano essere estesi e composti, in contrasto con Swing.

Nel complesso, suppongo che i dati concreti sui vantaggi siano ciò che mi manca per essere pienamente convinto da JavaFX.

D'altra parte, Swing è dimostrato e testato. Sì, l'API è goffa e invoca il completamento automatico nel tuo IDE su un oggetto Swing come JTextPane la farà piangere e piangere per la sua mamma, ma, se sei abbastanza ben informato, puoi creare fantastiche interfacce utente con Swing, che si stanno comportando bene (non ho mai comprato l'errore di Swing-ha-cattive prestazioni, vedi gli ex post sul blog di Romain Guy sui blog di Sun) e ti permettono di fare cose piuttosto ordinate.

Quindi, prima di cambiare qualsiasi cosa, ti consiglio di provare un piccolo prototipo e forse provare a portare alcune finestre di dialogo dell'applicazione e vedere come va.

Ho fatto molto JavaFX ora e lo preferisco a Swing. La struttura del grafico scena è diversa da quella a cui sei abituato con Swing, ma offre così tanti miglioramenti. L'API è divertente con cui lavorare, sembra rinfrescante.

C'è molto di più che puoi fare con esso, multimedia, animazione, navigazione web. Ad esempio, puoi creare un'applicazione Google Maps in poche righe di codice, incorporando html5 e javascript.

Si dice che sia incluso nel runtime Java 8, il che significherebbe la sostituzione definitiva di Swing come framework di interfaccia utente predefinito

@Migrazione : dovresti iniziare isolando parti dell'applicazione che possono essere convertite in JavaFX. L'interoperabilità di Swing-JavaFX 2 è una cosa importante, puoi usare javafx.embed.swing.JFXPanel per incorporare il tuo elemento JavaFX. Vedi interoperabilità swing-fx . (Per completezza puoi anche incorporare in SWT.)

Swing sta diventando una tecnologia legacy o lo è già. Tuttavia, è abbastanza buono in quello che fa e non se ne andrà in nessun futuro prevedibile, quindi non vedo alcun motivo per allontanarmi da esso, in particolare se uno ci ha già investito. Il software JIDE crea buoni componenti Swing (commerciali) per sostituire ciò che manca dallo Swing standard. Ad esempio, le treetable ordinabili sono nelle loro griglie fuori dalla scatola.

Mentre le nuove versioni di JavaFX sembrano molto impressionanti, dubito che valga la pena effettuare una migrazione completa a meno che non si desideri investire molto tempo / impegno / denaro in una revisione completa della GUI.

Swing può avere le sue stranezze e sta mostrando la sua età ma ha anche alcuni vantaggi:

• Funzionalità multipiattaforma molto forte, attualmente molto meglio di JavaFX
• È maturo e provato, molto più di JavaFX
• Ha un vasto ecosistema di comunità / librerie di utenti
• Probabilmente hai già molte abilità Swing o puoi assumere facilmente persone con loro

In definitiva, se non è rotto, perché ripararlo?

Certo, per un nuovo progetto guarderei molto seriamente JavaFX, Android e / o una GUI basata sul web (forse con qualcosa come Vaadin).

Sono nella stessa posizione dell'OP - avendo applicazioni swing legacy ma necessitando di implementare nuovi modi di dire e interfacce che non supporta in modo nativo. La più grande di queste applicazioni è stata rifattorizzata un paio di volte per vari motivi (migliorare la modularità, una migliore MVC e la struttura di invio degli eventi, ecc.), Quindi non sono completamente contrario a riscrivere il codice dell'interfaccia utente. Quindi ho riflettuto a lungo sul problema.

Tuttavia, alcune cose non possono essere risolte con Swing senza investire molto più tempo e sforzi in quella che è essenzialmente una tecnologia legacy. Ad esempio, oltre ai semplici eventi del mouse, i nuovi dispositivi touch-screen e non sono supportati dallo stesso Swing. Fornire un componente browser basato su Swing è altrettanto problematico o costoso e, nel mio caso, l'approccio javafx-in-swing non è un'opzione in quanto complica la gestione degli eventi dell'interfaccia utente in modi non banali.

Penso che sia stato il vecchio e fedele ai suoi tempi, e se la tua piattaforma è immutabile come la tua base di codice, mantienila, ovviamente. Ma affinché un'applicazione passi a nuovi casi d'uso più contemporanei, JavaFX 2+ sarà probabilmente il modo di procedere nel mio caso.

Come nota a margine: l'unica anomalia in Swing che mi sarebbe piaciuto sparire in jfx - ma non l'ho fatto - è l'approccio one-thread-to-rule-them-all all'invio di eventi UI. Qualsiasi interfaccia utente non banale necessita del multi-threading per mantenere l'interfaccia utente nitida e reattiva e lasciarla completamente allo sviluppatore dell'applicazione per inciampare nelle stesse insidie ​​così facilmente è un difetto nell'API IMHO.

Ho avuto una grande esperienza nell'uso di RCP in applicazioni desktop di grandi dimensioni. Fondamentalmente è iniziato come un'astrazione del livello GUI di Eclipse e da allora ha fatto molta strada. Invece di Swing, che si basa su AWT, RCP si basa su JFace, che a sua volta si basa su SWT. Ti consente di sviluppare applicazioni e utilizzare i concetti della GUI che Eclipse stesso utilizza (viste, editor, prospettive, procedure guidate, ecc.). È molto scalabile e, come lo stesso Eclipse, viene costantemente migliorato.

Tuttavia, non ho mai migrato un progetto esistente da Swing a RCP; Immagino che ci vorrebbe un po 'di tempo per avvolgere la testa attorno ai diversi paradigmi e se non hai separato il tuo modello e hai visto bene i livelli, avrai sicuramente dei momenti difficili. Ma dal momento che hai chiesto cose come le tabelle degli alberi ordinabili, RCP è fantastico in questo.

Se desideri ripeterlo ulteriormente, potresti provare il tutorial di Lars Vogel o dare un'occhiata ad alcuni esempi di progetti open source o progetti commerciali che utilizzano RCP.

(Ad esempio, una tabella ad albero ordinabile), comincio a sentire la difficoltà nel soddisfare le richieste. Questo è vero soprattutto perché non esiste uno sviluppo attivo attorno al progetto SwingX.

• non è vero, questo progetto è ancora vivo,

• blablabla una volta quando SwingX perse le sovvenzioni da parte di Sun (durante l'acquisizione da parte di Oracle) i popoli di SwingX andarono a costruire JavaFX

Inoltre, difficilmente riesco a trovare qualcosa di buono, pur essendo attivamente mantenuto / sviluppato / in evoluzione framework Java GUI.

• no Swing non riguarda Framework ma Look and Feel

• I frame sono per utenti non tecnici (MsAccess potrebbe essere l'esempio migliore per il framework GUI)

• ma se vuoi creare una vera applicazione hai una forte conoscenza di Swing e l'overriden proviene anche da Framework,

• esempio divertente Netbeans ha built_in Swing Framework basato su JSR296, ma non è possibile cambiare direttamente l'icona JFrames,

Hai iniziato a migrare il tuo progetto Swing verso un framework GUI sviluppato molto più attivo come JavaFX?

nessun motivo per cui

• lo stesso con la migrazione a Java7, forse quando ci sarà Java7.15 - 17

• Sto confrontando JavaFx con Nimbus, lo sviluppo si è concluso / arrendersi da qualche parte nel primo semestre

• scusa non sono uno sviluppatore, sono solo un fan di Java e Swing