Beginnen Sie mit der Migration Ihres Swing-Projekts nach JavaFX?

Ich habe ein 4 Jahre altes Projekt, das in Swing + SwingX geschrieben ist. Derzeit ist es noch am Leben und immer noch munter.

Da jedoch mehr GUI-bezogene Feature-Anfragen eingehen (zum Beispiel eine sortierbare Baumtabelle), habe ich das Gefühl, dass es schwierig ist, die Anfragen zu erfüllen. Dies gilt insbesondere, da es keine aktive Entwicklung rund um das SwingX-Projekt gibt.

Außerdem kann ich kaum ein gutes, aber aktiv gepflegtes / entwickeltes / sich entwickelndes GUI-Java-Framework finden.

Ich habe mich gefragt, ob einer der Swing-Entwickler dasselbe empfindet. Haben Sie begonnen, Ihr Swing-Projekt auf ein viel aktiver entwickeltes GUI-Framework wie JavaFX zu migrieren?

Ich persönlich wechsele zu JavaFX (2.1+, nicht die alte seltsame 1.x-Version mit der fiesen Skriptsprache). Das neue JavaFX ist nicht zu 100% perfekt, aber es ist schon ein verdammt angenehmerer Anblick als Swing, ich sehe eine vernünftige Zukunft für es (insbesondere angesichts der eingebetteten Webkit-Engine).

Ich frage mich oft das Gleiche, aber ich glaube nicht, dass ich bestehende Projekte nach JavaFX migrieren würde. Zumindest vorerst nicht und nicht für mittlere bis große Projekte. Ich würde jedoch JavaFX für neue Projekte in Betracht ziehen und in Zukunft erneut über eine Migration nachdenken und die Frage nach dem Fortschritt von JavaFX neu bewerten.

Im Moment sind meine Bedenken:

• Unreife

  Ja, wir werden bald auf 3.0 umsteigen, aber es ist noch nicht so lange her und wir haben noch große Veränderungen durchgemacht. Für große und risikoaverse Unternehmenssoftware ist dies ein relativ schmerzhafter Punkt.

• Performance

  Ich habe nicht genug Daten zu Leistungsunterschieden gesehen.

• Widgets und Komponenten

  Ich habe nicht genug Gewinn in den neuen Komponenten gesehen. Das kann mit Unreife zusammenhängen, denke ich. Ich weiß auch noch nicht, wie gut sie im Gegensatz zu Swing erweitert und komponiert werden können.

Insgesamt denke ich, dass es mir an harten Daten zu den Vorteilen mangelt, um von JavaFX voll überzeugt zu sein.

Zum anderen ist Swing bewährt und erprobt. Ja, die API ist klobig und das Aufrufen der automatischen Vervollständigung in Ihrer IDE für ein Swing-Objekt wie das JTextPane bringt es zum Weinen und Weinen um seine Mutter, aber wenn Sie über ausreichende Kenntnisse verfügen, können Sie mit Swing fantastische Benutzeroberflächen erstellen gute Leistungen (ich habe nie den Trugschluss gekauft, dass Swing schlechte Leistungen erbringt, siehe Romain Guys frühere Blog-Beiträge in Suns Blogs) und erlaube dir, ziemlich nette Dinge zu tun.

Bevor Sie also etwas ändern, empfehlen wir Ihnen, zunächst einen kleinen Prototypen zu testen und möglicherweise einige Dialogfelder Ihrer Anwendung zu portieren, um zu sehen, wie es funktioniert.

Ich habe jetzt viel JavaFX gemacht und ich bevorzuge es gegenüber Swing. Die Struktur des Szenendiagramms unterscheidet sich von der von Swing, bietet jedoch viele Verbesserungen. Die API macht Spaß, es fühlt sich erfrischend an.

Es gibt so viel mehr, was Sie damit machen können: Multimedia, Animation, Surfen im Internet. Sie können beispielsweise eine Google Maps-Anwendung in wenigen Codezeilen erstellen und dabei HTML5 und Javascript einbetten.

Es soll in der Java 8-Laufzeit enthalten sein, was bedeutet, dass Swing als Standard-UI-Framework definitiv ersetzt wird

@Migration : Sie sollten zunächst Teile Ihrer Anwendung isolieren, die in JavaFX konvertiert werden können. Die Interoperabilität von Swing-JavaFX 2 ist eine große Sache. Sie können das javafx.embed.swing.JFXPanel verwenden, um Ihr JavaFX-Element einzubetten. Siehe Swing-FX-Interoperabilität . (Der Vollständigkeit halber können Sie auch in SWT einbetten.)

Swing wird zu einer Legacy-Technologie oder ist es bereits. Es ist jedoch recht gut in dem, was es tut, und wird in absehbarer Zukunft nicht verschwinden. Daher sehe ich keinen Grund, davon abzuweichen, insbesondere wenn man bereits in es investiert hat. JIDE Software macht gute (kommerzielle) Swing-Komponenten, um das zu ersetzen, was im Standard-Swing fehlt. Zum Beispiel ist sortierbar TreeTable in ihren Netzen aus dem Kasten heraus .

Obwohl die neuen JavaFX-Versionen sehr beeindruckend aussehen, bezweifle ich, dass es sich lohnt, eine vollständige Migration durchzuführen, es sei denn, Sie sind bereit, viel Zeit, Mühe und Geld in eine vollständige Überarbeitung der Benutzeroberfläche zu investieren.

Swing mag seine Macken haben und zeigt sein Alter, hat aber auch einige Vorteile:

• Sehr starke plattformübergreifende Fähigkeit, derzeit viel besser als JavaFX
• Es ist ausgereift und bewährt, viel mehr als JavaFX
• Es hat eine große Benutzergemeinschaft / Bibliothek Ökosystem
• Du hast wahrscheinlich schon viele Swingfähigkeiten oder kannst leicht Leute mit ihnen einstellen

Letztendlich, wenn es nicht kaputt ist, warum es reparieren?

Natürlich würde ich für ein neues Projekt JavaFX, Android und / oder eine webbasierte Benutzeroberfläche (vielleicht mit etwas wie Vaadin) sehr ernst nehmen.

Ich bin in der gleichen Position wie das OP - mit älteren Swing-Anwendungen, aber ich muss neue Redewendungen und Schnittstellen implementieren, die es von Haus aus nicht unterstützt. Die größte dieser Anwendungen wurde aus verschiedenen Gründen mehrmals überarbeitet (Verbesserung der Modularität, Verbesserung der MVC- und Event-Dispatch-Struktur usw.), so dass ich nicht völlig abgeneigt bin, den UI-Code neu zu schreiben. Also habe ich lange und gründlich über das Thema nachgedacht.

Einige Probleme lassen sich mit Swing jedoch nicht lösen, ohne viel mehr Zeit und Mühe in eine herkömmliche Technologie zu investieren. Beispielsweise können andere als einfache Mausereignisse neue Touchscreen-Geräte sein und werden von Swing selbst nicht unterstützt. Die Bereitstellung einer Swing-basierten Browserkomponente ist ähnlich mühsam oder teuer, und in meinem Fall ist der Javafx-in-Swing-Ansatz keine Option, da er die Ereignisbehandlung in der Benutzeroberfläche auf nicht triviale Weise erschwert.

Ich denke, es war zu seiner Zeit das Alte und Getreue, und wenn Ihre Plattform so unverändert ist wie Ihre Codebasis - bleiben Sie offensichtlich dabei. JavaFX 2+ ist in meinem Fall wahrscheinlich der richtige Weg, um eine Anwendung in neuere Anwendungsfälle zu integrieren.

Als Randnotiz: Das einzige Missfeature in Swing, das ich gerne in jfx verschwunden wäre - aber nicht -, ist der Ein-Thread-zu-Regel-für-Alle-Ansatz für den UI-Event-Versand. Jede nicht-triviale Benutzeroberfläche benötigt Multithreading, um die Benutzeroberfläche klar und reaktionsschnell zu halten, und es dem Anwendungsentwickler zu überlassen, über dieselben Fallstricke zu stolpern, ist ein Mangel in der API IMHO.

Ich habe große Erfahrung mit RCP in großen, desktopbasierten Anwendungen. Es begann im Grunde genommen als Abstraktion der GUI-Ebene von Eclipse und hat seitdem einen langen Weg zurückgelegt. Anstelle von Swing, das auf AWT basiert, baut RCP auf JFace auf, das wiederum auf SWT basiert. Sie können Anwendungen entwickeln und die von Eclipse selbst verwendeten GUI-Konzepte (Ansichten, Editoren, Perspektiven, Assistenten usw.) verwenden. Es ist sehr skalierbar und wird wie Eclipse selbst ständig verbessert.

Ich habe jedoch noch nie ein vorhandenes Projekt von Swing auf RCP migriert. Ich würde mir vorstellen, dass es eine Weile dauern würde, sich mit den verschiedenen Paradigmen auseinanderzusetzen, und wenn Sie Ihr Modell und Ihre Ansichtsebenen nicht gut voneinander getrennt haben, wird es Ihnen sicher schwer fallen. Aber da Sie nach Dingen wie sortierbaren Baumtabellen gefragt haben, ist RCP darin großartig.

Wenn Sie dies weiter erforschen möchten, können Sie das Tutorial von Lars Vogel ausprobieren oder sich einige Beispiele für Open-Source-Projekte oder kommerzielle Projekte ansehen , die RCP verwenden.

(Zum Beispiel eine sortierbare Baumtabelle) Ich beginne die Schwierigkeit zu spüren, die Anfragen zu erfüllen. Dies gilt insbesondere dann, wenn das SwingX-Projekt nicht aktiv weiterentwickelt wird.

• nicht wahr, wieder ist dieses Projekt am Leben,

• blablabla Einmal, als SwingX die Berechtigungen von Sun verlor (während der Übernahme durch Oracle), gingen die Leute von SwingX zu JavaFX

Außerdem kann ich kaum ein gutes, noch aktiv gepflegtes / entwickeltes / sich entwickelndes GUI-Java-Framework finden.

• Bei no Swing geht es nicht um Framework, sondern um Look and Feel

• Frameworks sind für nicht technische Benutzer (MsAccess ist möglicherweise das beste Beispiel für GUI Framework).

• Wenn Sie jedoch eine echte Anwendung erstellen möchten, verfügen Sie über fundierte Kenntnisse in Bezug auf Swing und Overriden, die auch von Framework stammen.

• lustiges Beispiel Netbeans hat ein auf JSR296 basierendes Swing Framework eingebaut, aber es ist nicht möglich, das JFrames Icon direkt zu ändern.

Haben Sie begonnen, Ihr Swing-Projekt auf ein viel aktiver entwickeltes GUI-Framework wie JavaFX zu migrieren?

Kein Grund warum

• Gleiches gilt für die Migration auf Java7

• Ich vergleiche JavaFx mit dem Nimbus, die Entwicklung endete / gab irgendwann in der ersten Hälfte auf

• Entschuldigung, ich bin kein Entwickler, ich bin nur Java & Swing Fan