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

Personalmente sto passando a JavaFX (2.1+, non la vecchia versione 1.x strana con il linguaggio di scripting cattivo). Il nuovo JavaFX non è perfetto al 100%, ma è già una visione più piacevole da usare rispetto a Swing, vedo un ragionevole futuro per esso (soprattutto dato il motore Webkit incorporato).

Mi chiedo spesso la stessa cosa, ma non penso che migrerei i progetti esistenti in JavaFX. Almeno non per ora, e non per progetti di dimensioni medio-grandi. Tuttavia, prenderei in considerazione JavaFX per i nuovi progetti e prendere in considerazione una migrazione in futuro e rivalutare le domande sulla base dei progressi di JavaFX.

Al momento, le mie preoccupazioni sono:

• L'immaturità

  Sì, presto andremo a 3.0, ma non è stato intorno così a lungo, e abbiamo ancora attraversato importanti cambiamenti. Quindi per i software aziendali di grandi dimensioni e avversi al rischio, questo è un punto relativamente dolente.

• Performance

  Non ho visto abbastanza dati rigidi sulle differenze di prestazioni.

• Widget e componenti

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

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

D'altra parte, Swing è provato e testato. Sì, l'API è goffo e invoca il completamento automatico nel tuo IDE su un oggetto Swing come il JTextPane lo farà piangere e piangere per la sua mamma, ma, se sei abbastanza informato, puoi costruire fantastiche interfacce utente con Swing, che stanno andando bene (non ho mai comprato l'errore di Swing-have-bad-performance, vedi gli ex post di Romain Guy sui blog di Sun) e ti permettono di fare cose molto belle.

Quindi, prima di passare a qualcosa, ti consiglio di provare prima un piccolo prototipo e magari provare a portare alcune finestre di dialogo dell'applicazione e vedere come va.

Ho fatto un sacco di JavaFX ora e lo preferisco su Swing. La struttura di Scene Graph è diversa da quella a cui sei abituato con Swing, ma offre molti miglioramenti. L'API è divertente da usare, si sente rinfrescante.

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

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

@Migration : dovresti iniziare isolando parti della tua applicazione che possono essere convertite in JavaFX. L'interoperabilità di Swing-JavaFX 2 è una grande cosa, è possibile utilizzare javafx.embed.swing.JFXPanel per incorporare l'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 sta andando via in un futuro prevedibile, quindi non vedo alcun motivo per allontanarmi da esso, in particolare se uno ha già investito in esso. JIDE Software rende buoni componenti (commerciali) Swing per sostituire ciò che manca dallo Swing standard. Ad esempio, ordinabile treetable è nella loro griglie fuori dalla scatola.

Anche se le nuove versioni di JavaFX sembrano davvero impressionanti, dubito che valga la pena eseguire una migrazione completa a meno che non si sia disposti a investire molto tempo / sforzi / soldi in una revisione completa della GUI.

Lo swing può avere le sue peculiarità e mostra la sua età, ma presenta anche alcuni vantaggi:

• Capacità cross-platform molto strong, attualmente molto meglio di JavaFX
• È maturo e comprovato, molto più di JavaFX
• Ha un grande ecosistema di comunità / biblioteca utente
• Probabilmente hai già un sacco di abilità Swing o puoi assumere persone facilmente con loro

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

Naturalmente, 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 ho bisogno di implementare nuovi idiomi e interfacce che non supporta nativamente. La più grande di queste applicazioni è stata rifattorizzata un paio di volte per vari motivi (migliorare modularità, MVC migliore e struttura di invio degli eventi, ecc.) Quindi non sono del tutto contrario alla riscrittura del 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 su ciò che è essenzialmente una tecnologia legacy. Ad esempio, diversi da semplici eventi del mouse, nuovi dispositivi touch-screen e non supportati da Swing stesso. Fornire un componente del 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 UI in modi non banali.

Penso che sia stato il vecchio e fedele a suo tempo, e se la tua piattaforma è immutabile come la tua base di codice - continua ad esserlo, ovviamente. Ma perché un'applicazione possa andare avanti in nuovi casi d'uso più contemporanei, JavaFX 2+ sarà probabilmente il modo di andare avanti nel mio caso.

Come nota a margine: l'unica disfunzione di Swing che avrei preferito scomparire in jfx - ma non l'ho fatto - è l'approccio one-thread-to-rule-them-all alla distribuzione degli eventi dell'interfaccia utente. Qualsiasi interfaccia utente non banale ha bisogno di multi-threading per mantenere l'interfaccia utente nitida e reattiva, e lasciare tutto allo sviluppatore dell'applicazione per inciampare sulle stesse insidie è così facilmente un difetto nell'IMHO dell'API.

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

Tuttavia, non ho mai migrato un progetto esistente da Swing a RCP; Immagino che ci vorrà un po 'di tempo per avvolgere la testa intorno ai diversi paradigmi e se non hai separato bene il tuo modello e i livelli di visualizzazione, sei destinato ad avere un momento difficile. Ma dal momento che hai chiesto cose come le tabelle degli alberi ordinabili, RCP è fantastico.

Se desideri approfondire ulteriormente questo argomento, ti consigliamo di provare Lars Vogel's tutorial o dare un'occhiata ad alcuni esempi di progetti open source o progetti commerciali che utilizzano RCP.

(For instance, a sortable tree table), I start to feel the difficulty in fulling the requests. This is true especially there isn't active development going around SwingX project.

• non è vero, di nuovo questo progetto è vivo,

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

Also, I hardly can find any good, yet being actively maintained/ developed/ evolving GUI Java framework.

• no Swing non riguarda Framework ma Aspetto e tatto

• I framework sono per utenti non tecnici (MsAccess potrebbe essere il miglior esempio di GUI Framework)

• ma se vuoi creare un'applicazione reale hai delle conoscenze approfondite su Swing e overriden proviene anche da Framework,

• esempio divertente Netbeans ha incorporato in Swing Framework basato su JSR296, ma non è possibile modificare direttamente l'icona di JFrames,

Have you start to migrate your Swing project to a much more active developed GUI framework like JavaFX?

nessun motivo per cui

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

• Sto comparando JavaFx con il Nimbus, lo sviluppo è terminato / ceduto da qualche parte nella prima metà

• scusa non sono uno sviluppatore, sono solo Java e amp; Fan di swing