ich habe damals viel mit AutoIT gescript (man kann viel damit machen! doch nur unter Windows… ) und wollte mal eine echte Programmiersprache kennenlernen…bin nun zu Java gelandet, nicht ganz, ich schwanke zw. QT5 & C++ und Java… die QT Doku ist einfach nur TOP und auch leicht zu verstehen… man sollte jedoch C++ Grundlage kennen wenn man wirklich gute Programme schreiben möchte… man kann aber auch vieles mit PyQt erreichen oder in Verbindung mit Perl… was ich auch interessant finde ist das; http://en.wikipedia.org/wiki/FXML …alles schön&gut, doch trotzdem finde ich JavaFX irgendwie interessanter…
meine frage: warum benutzen die meisten hier Swing? so weit ich verstanden habe kann man JavaFX auch in Verbindung mit Swing benutzen, doch die meisten tun es trotzdem nicht…? gibt es ein bestimmten Grund? würde mich echt interessieren…
Swing ist viel älter, JavaFX war lange Zeit nur umständlich über XML zu benutzen (was viele nachhaltig abgeschreckt hat), war zwischenzeitlich schon halbtot, und eine klare Linie fährt Oracle trotz Reanimation in dieser Frage auch nicht. Außerdem ist inzwischen die Frage nach einem geeigneten Web-Framework für viele Leute (einschließlich mir) wesentlich interessanter. Und wer gute Oberflächen programmieren will, kann das eben auch mit Swing, wo der gute Tool-Support und externe Komponenten inzwischen manche Unbequemlichkeiten und konzeptionelle Lücken überbrücken helfen.
Ich würde also sagen, dass es eher “politische” als technische Gründe sind.
ich finde die Tutorials für Swing ausführlicher und man findet wirklich vieles, so kann man ungefähr sehen was damit asp möglich ist…ist sicherlich auch ein Grund? ich meine, bei JavaFX ist das leider nicht der Fall… durch die paar Tutorials werde ich (ehrlich gesagt) überhaupt nicht klüger…
[QUOTE=Landei;73208] klare Linie fährt Oracle trotz Reanimation in dieser Frage auch nicht. Außerdem ist inzwischen die Frage nach einem geeigneten Web-Framework für viele Leute (einschließlich mir) wesentlich interessanter. Und wer gute Oberflächen programmieren will, kann das eben auch mit Swing, wo der gute Tool-Support und externe Komponenten inzwischen manche Unbequemlichkeiten und konzeptionelle Lücken überbrücken helfen.
[/QUOTE]
Der Wind dreht sich langsam wieder, weil es einige Projekte mit JavaFX als RIA gibt. Ob sich JavaFX durchsetzt wird daran liegen, ob es auf iOS und Android kommt.
Hier ist ein ganz netter Vortrag:
*** Edit ***
JavaFX ist eben einfach neuer, und wird bald auch mit dem JDK ausgeliefert. Viele alten Anwendungen sind eben noch in Swing und portieren kostet eben Geld. Neuere Projekte werden schon mit JavaFX umgesetzt (aber meistens mit einem Framework) oder eben als Webwanwendung
Ein Grund kann auch die Geschichte sein, die JavaFX hinter aich hat. Anfangs von einer reinen Skriptsprache (1.x glaibe ich) bis hin zu einem komplett neuen Framework(2.x) welches nun auch mehr als nur ein Fenster mit dem Button beherrscht… Da sich da sehr sehr viel veraendert hat und zwar nicht nur an den Features sondern primaer an der API und den Aufbau(Applikationen mit FX1.x sind nicht kompatibel mit 2.x) hat das wahrscheinlich vieler Entwickler abgeschreckt. Denn wer will ne Applikation haben die nach einem halben Jahr nicht mehr geht, da der komplette Core ueberarbeitet wurde…
was hier im Forum besprochen wird, falls das zum Eindruck führt, sind doch eh eher Anfänger-Geh-Versuche,
da ist es allein schon ein enormer Vorteil, dass Swing in der Standard-API drin ist,
jedes Einfügen einer Jar ein gewisses Problem, dann noch verschiedene Versionen vielleicht, unpassende Tutorials/ Beispiele usw.,
JButton und ActionListener funktionieren heute wie vor 10 Jahren,
nicht schön aber robust und irgendwie bekannt
Ich denke, die wichtigsten Punkte wurden schon genannt (Swing war zuerst da, JavaFX am Anfang eine Scriptsprache, jetzt ist es (in Version 2.x) neu und noch nicht so “etabliert”).
Ich finde, JavaFX hat einige ziemlich coole Features - das “Data Binding”, das eingebaut ist, und mächtige Componenten… wenn man sich mal die http://docs.oracle.com/javafx/2/charts/jfxpub-charts.htm anschaut, und sich überlegt, wie absurd aufwändig es wäre, sowas mit Swing nachzubauen, ist das schon ein Argument. Was mir noch etwas sauer aufstößt ist dieses CSS-styling. Einerseits: Sau-Cool. Man kann seine komplette Applikation über CSS “skinnen”. Andererseits: Man MUSS seine komplette Applikation über CSS “skinnen”: Ein einfaches chart.getBar(2).setColor(Color.RED) gibt’s nicht mehr. Stattdessen wühlt man sich durch irgendwelche anonymen Nodes, wurstet da CSS-Strings rein, und hofft, keinen Tippfehler gemacht zu haben… (aber vielleicht gibt’s dafür auch eine “coole” Lösung, die ich nur noch nicht gefunden habe…)
Zudem bereits gesagten will ich noch folgendes ergänzen: Swing hat, vermutlich auch eben wegen des Alters, auch dazu gefürt, dass es sehr viele Libs und auch das eine oder andere Framework gibt, das auf Swing basiert. JavaFX steckt noch in den Kinderschuhen. Und gerade Business-Anwendungen (z.B. Vertragsverwaltung) werden oft als MDI-System umgesetzt und Swing unterstützt eben dafür passend JInternalFrames. JavaFX hat sowas noch gar nicht. Oracle hat zwar versprochen das nachzurüsten, bislang ist aber nichts passiert. Das führt gleichzeitig auch eben zu dem Punkt mit den Libs. Für Swing gibt es einiges, ist nicht die Welt, aber da gibt es was. Für JavaFX existiert noch nahezu überhaupt nichts. Und Betriebe, die eigene Komponenten auf Swing-Basis geschrieben haben, müssten all das wieder zu JavaFX portieren. Das Budget dafür wird kaum jemand einfach so freigegeben bekommen, da es einfach nicht nötig ist und da die Zukunft von JavaFX trotz Pushens seitens Oracle noch ungeklärt ist, wird da auch kaum jemand seinen Kopf für hinhalten und lieber weiter mit Swing-Basis arbeiten.
Zu der Sache mit JavaFX in Swing: Ja, das ist möglich. Das macht aber kaum Sinn, umgekehrt wäre es durchaus sinnvoller, denn dann könnte man seine eigenen auf Swing basierenden Komponenten nutzen und so einen sanften Übergang der Software von einer Technologie in die andere überführen. Geht aber nicht. Außerdem funktioniert das auch nicht so reibunglos, wie viele denken. In den Getting Started Tutorials sieht das immer so leicht aus, man packt einen JavaFX-Container in seine Swing-Anwendung und kann sofort loslegen. Nur was wird in den Beispielen meist gemacht? Ein Button und ein Textfeld hinzugefügt und Hallo Welt ausgegeben. Tolles fachliches Beispiel! Also versucht man es und kaum bekommt die Anwendung ein paar Komponenten, sowohl auf Swing- als auch auf JavaFX-Seite und noch ein bisschen Logik, schon knallt es überall, weil z.B. der EDT und der JavaFX Application Thread und eventuell noch andere sich gegenseitig auf die Mütze hauen. Eine komplexe Anwendung mit diesem Mischmasch zu erstellen ist nicht so einfach, wie es bei diesen HelloWorld-Beispielen immer gezeigt wird. Da funktioniert das super, da wird aber auch nichts gemacht. Und ich habe das auch von einigen anderen mitbekommen. Also entweder Swing oder JavaFX verwenden, aber beides mischen dann eben auf eigene Gefahr.
Echt das wäre mir neu, Button usw. kann man doch alles doch so stylen? Aber ich finde es schon besser mit CSS zu machen. Gibt vom Tom Schindl einen überragenden Editor auf xText Basis.
(nur schnell aus http://stackoverflow.com/questions/14158104/javafx-barchart-color übernommen), und nicht mit dem angedeuteten chart.getBar(0).setColor(RED);. Und das Problem ist: Die Strings, die dort verwendet werden sind praktisch undokumentiert, wenn man mal von sowas wie http://docs.oracle.com/javafx/2/api/javafx/scene/doc-files/cssref.html absieht - da muss man sich in einem Maße mit CSS auskennen, das man (sich natürlich erarbeiten kann, aber) nicht von vornherein erwarten kann. Die Strings werden nicht ge-syntax-checkt, und wenn man den kleinsten Fehler macht, passiert … nichts. Und den Fehler dann zu finden, ist schwierig. e(fx)clipse kenne ich, allerdings hatte ich mir das nur damals, als es “neu” war, kurz angesehen - da war es schon noch SEHR beta und SEHR umständlich zu verwenden. Inzwischen dürfte das besser sein, und sowas wie die CSS-autocompletion schwächt obige Kritik natürlich ab, aber … es ist eben noch nicht völlig in der Toolchain angekommen. Wird sicher noch.
Aus diesem Grund gewinnen RIA’s und modellierte UI’s immer mehr an Popularität. Einfach UI Renderer tauschen und fertig.
Bei CaptainCasa hat das funktioniert Swing Renderer durch JavaFX Renderer ausgetauscht. Backend JSF bleibt genau das gleiche man musste am eigenen Code nix ändern und fertig.
Wie gesagt so intensiv hab ich mir noch nicht damit beschäftigt ;), aber wird mit der Zeit bestimmt kommen. Kann dir fx eclipse empfehlen, dass war bis jetzt das beste Tooling für JavaFX vor allem auch im Zusammenhang mit Eclipse e4. Ich würde das ganze außen herum gar nicht erst anders anfangen.
[QUOTE=SirWayne]Aus diesem Grund gewinnen RIA’s und modellierte UI’s immer mehr an Popularität. Einfach UI Renderer tauschen und fertig.
Bei CaptainCasa hat das funktioniert Swing Renderer durch JavaFX Renderer ausgetauscht. Backend JSF bleibt genau das gleiche man musste am eigenen Code nix ändern und fertig.[/QUOTE]
Bei einigen Faellen mag das gut funktionieren, doch bei zb reinen Swing Desktop applikationen kann man nicht mal eben schwupps was austauschen.
Und natuerlich, wenn man nun auf neuere Technologien setzt, so hat mans einfach. Aber wenn man so die Industrie (und vor allem die Kunden !) kennt, so ists eben nicht der oeftere Fall.
Wenn man heutzutage nicht mehr Cobalt programmieren wuerde… ach halt momentan
Vor allem wer soll das bitte bezahlen? Bei Standardsoftware, die verkauft wird, ist das ja noch eine Sache. Aber bei Individualsoftware maßgeschneidert für einen bestimmten Kunden müsste die Portierung und alles was damit zusammen hängt der Kunde tragen. Unsere Kunden würden uns was husten, wenn wir denen sowas auf die Rechnung setzen. Vorteile hin oder her, dass eine neuere Technologie besser sein soll ist kein Grund, warum ein Kunde das Neuschreiben der Software, die er ohnehin schon bezahlt hat, nochmal finanzieren soll, um am Ende das gleiche in grün zu bekommen.
alter … erlich … wie lächerlich kann man sich eigentlich machen ?
im nächsten post verweist du sogar noch selbst auf wiki, wo mal eben schon ganz oben steht das JavaFX seit Java7u6 mit dabei ist … hättest du vielleicht vorher mal SELBST reingucken sollen
BTT
auch wenn JavaFX wie erwähnt seit Java7u6 nun bestandteil einer Java-installation ist und damit halt seitens oracle gepusht wird fehlt irgendwie der status „für den produktiveinsatz bereit“
ich arbeite täglich mit einer in java geschriebenen software, natürlich ist die GUI in Swing geschrieben, und hat, warum auch immer, ein eigenes LaF
ich weis nicht wie es bei JavaFX aussieht in richtung LaF, ob es sowas überhaupt gibt oder unterstützt wird, aber fakt ist das halt gerade was custom-software angeht es sehr viele LaF im netz gibt, oder man hat sich halt über die jahre sein eigenes gebaut, das jetzt umzusetzen in JavaFX währe auch wieder aufwand den man sich sparen kann wenn man einfach weiter Swing nutzt
dann kommt es auch noch auf die performance an : gerade im produktiven einsatz ist es meist so das die rechner von der leistung her gerade so ausreichend für die tägliche arbeit gekauft werden, hier hilft es genau zu wissen wie resourcen-hungrig java ist, in diesem fall genauer gesagt die anbindung ans OS für die graphische darstellung
ich gehe mal von aus das hier JavaFX noch nicht stabil sein wird, oder wenn schlicht zu hohe anforderung an vorhandene hardware stellt
nicht jeder kann sich mal eben für ein paar tausende ein paar hundert rechner leisten nur weil der software-entwickler meint auf JavaFX upzudaten, vom aufwand für die IT-abteilung mal abgesehen
wie man es dreht und wendet, JavaFX mag zwar mitlerweile seine vorzüge haben, und für das eine oder andere projekt auch bereit sein, aber für die breite masse ist Swing einfach nur „notwendig“
[QUOTE=bygones]Bei einigen Faellen mag das gut funktionieren, doch bei zb reinen Swing Desktop applikationen kann man nicht mal eben schwupps was austauschen.
[/QUOTE]
Ich hab auch gesagt dass solche Lösungen für neue Produkte beliebter werden, weil die Manager merken ahhhhhh kostet ganz schön Geld sowas zu portieren. Damals gab’s die Ideen vielleicht,aber die Technologien sind doch um einiges besser gerade…
Je nachdem manche Kunde zahlen für ein neues major Release mit besseren, schöneren UI oder vielleicht ist es dann auch schon ein ganz neues Produkt… Aber so pauschalieren würde ich das nicht und auch eine Individualsoftware kann eine RIA sein und dann ist die Portierung doch gar kein Problem, aber anderes Thema…
*** Edit ***
[QUOTE=Unregistered;73334]alter … erlich … wie lächerlich kann man sich eigentlich machen ?
im nächsten post verweist du sogar noch selbst auf wiki, wo mal eben schon ganz oben steht das JavaFX seit Java7u6 mit dabei ist … hättest du vielleicht vorher mal SELBST reingucken sollen
[/QUOTE]
Alter kannst dein 1. Sohn nennen du Kasper. Nur weil du es mit Java7u6 mit ausgeliefert wird, ist es noch lange nicht eingebunden, das wird erst mit Java8 passieren. Lad es dir runter und schau mal wie JavaFX in 7 eingebunden ist man man immer gleich groß Aufklären wollen aber kein Plan haben…
[QUOTE=Unregistered;73334]
wie man es dreht und wendet, JavaFX mag zwar mitlerweile seine vorzüge haben, und für das eine oder andere projekt auch bereit sein, aber für die breite masse ist Swing einfach nur „notwendig“[/QUOTE]
Ach ja??? Interessant!!! Du denkst zuviel an Fat Clients und an keine dynamische und modulare Anwendungen und verteilte Anwendungen. Das man alte Swing Anwendungen jetzt vielleicht nicht portiert, okay ist das eine, aber für neue Software auf eine FAT Swing Anwendung zu setzen ist ja wohl mehr als lächerlich…
…alles schön&gut, doch trotzdem finde ich JavaFX irgendwie interessanter… 
wie kann oder soll ich das verstehen?