Hey,
hab seit einer Woche mit JavaFx angefangen davor noch nie was mit GUI gemacht, ich würde gerne wissen welche funktionen hat Javafx die, die anderen Frameworks nicht haben?
3D kann javaFX das weiß ich, obs die anderen können weiß ich nicht, was gibts da noch?
Das mit dem 3D könnte Swing auch.
Den größten Fortschritt brachte JavaFX für die Umsetzung des MVC-Patterns. Bei Swing sind View und Controller doch recht eng miteinander verzahnt. JavaFX erlaubt duch die Bindings und die deklarative Konfiguration der GUI in XML eine bessere Trennung.
bye
TT
Hi,
ich hab mal zu JDK 7ner Zeiten JavaFx benutzt um mir Aktienkurse anzeigen zu lassen. Das ging sogar relativ flott und sah auch schön aus.
Allerdings frage ich mich wieso Oracle so viele Ressourcen darein investiert hat. Werden irgendwo wirklich noch Client Java Programme mit GUI geschrieben? Alternativen dafür gibt es mit Vaadin, GWT, Play genug (wird zu JS kompliert ist daher im Browser lauffähig)
JavaFx passt irgendwie nicht so recht in die Java Welt. Es gibt ein sehr gutes Ressourcen Binding Konzept, dass allerdings in JavaFx packages liegt (FXCollections kommen mir in den Sinn). Warum auch immer. Die GUI selbst wird mit dem Fxml geschrieben, was auch nicht wirklich passt, wahrscheinlich aber die Portabilität erhöht.
In der Java Welt wäre SWING eine alternative, diese wird allerdings nicht mehr gepflegt sieht auch noch sehr altbacken aus.
Ich denke nicht das JavaFX Oracle besonders viel eingebracht hat. Dafür sind sie ein paar Jahre zu spät dran.
Oben angesprochene Frameworks kommunizieren mit einem Java Server laufen aber selbst JVM unabhängig in einem Browser (der Client umfasst trotzdem noch JavaCode), sind so um einiges Portabler als JavaFX.
Völlig egal, was JavaFX kann oder nicht kann (ein paar Kleinigkeiten sind es schon und wurden schon angesprochen: einfaches 3D mit OpenGL, Binding, CSS,…)
Im Prinzip ist es FAST unmöglich, ein sicheres, schnelles, multi-threaded GUI-Framework zu schreiben: Swing war nach 10 Jahren zwar ausgereift, ist aber jetzt altbacken und langfristig ein totes Gleis.
JavaFX ist halt das aktuelle Zeugs in der Java-GUI-Programmierung, also sollte man das auch einsetzen.
Interessiert nicht - der Trend geht eher wieder zurück zu native-GUI-Anwendungen wo dies erforderlich ist. Bis jemand 60fps schnelle Javascript-Anwendungen im Browser mit dem ähnlich mühelosen Look-And-Feel einer guten Swing oder JavaFX Anwendung schreibt dürfte es noch 10 oder 20 Jahre dauern.
Stimmt nur teilweise: Das Java zu Javascript transpilen bindet auch den Client völlig an das Java-Backend. Natürlich können ein paar Freaks gerne ein PHP oder Ruby Backend für einen Vaadin/GWT Client programmieren - aber mit „Portabilität“ hat das nichts zu tun.
Im übrigen: SW die (aus welchen Gründen auch immer) stand-alone laufen sollen würden den Betrieb eines lokalen HTTP-Servers erfordern. In großen Firmen mit der üblichen verrückten IT-Abteilung machen die Verhandlungen über solche Installationen nicht wirklich Spass. Dazu alte Browser und die trotz aller Versprechungen immer noch vorhandnen JS-Quirks - so richtig toll ist das Gepfriemel mit den Browser-Shims auch nicht…
fps? 
eine GUI ist doch normalerweise höchst statisch, da bewegt sich gar nichts, wie auch die Menüs und Co. des Browsers an denen gerade die meisten sitzen dürften,
browser-kritisch wichtig ist schnelle Reaktionszeit auf Aktionen, schneller Aufbau der neuen Seite,
ein Frame quasi ab und zu, dieses freilich möglichst schnell, in 1/60 sec gerne, bei echter Netzwerkbeteiligung kaum zu erreichen
Verbreitung ist immer schwierig, die einzelnen öffentlichen Programme, von Tausenden genutzt, sind nur eine Seite der Medaille,
auf der anderen Seite steht jede Firma mit evtl. eigener Software einzeln, was dort im Einsatz?
bei uns seit Jahren Java-GUI weiterzuentwickeln, potentiell tausende GUIs = 99% der Arbeit für Programmierer,
[quote=SlaterB]browser-kritisch wichtig ist schnelle Reaktionszeit auf Aktionen, schneller Aufbau der neuen Seite,
ein Frame quasi ab und zu, dieses freilich möglichst schnell, in 1/60 sec vielleicht, bei echter Netzwerkbeteiligung kaum zu erreichen[/quote]
Ja eben: Browser-kritisch. Das interessiert den Anwender überhaupt nicht. Das ist die falsche Perspektive: Der Browser ist ein Hinkebein, also muss ich meine Software daran anpassen.
Typische Anwender einer Fat-GUI (Photoshop, AutoCAD, Excel, …) denken nicht so, da flutscht der Aufbau von Menus, StrgCStrgV, das Befüllen mit Daten, verschieben von Fenstern usw. nur so - wird lange dauern bis Javascript da mithalten kann (auch wenn es in die Richtung geht, schon klar).
Stimmt, aber es gibt auch Leute die Arbeiten - bei denen fliegen die Sachen am Bildschirm nur so herum 
So kritische GUIS werden aber selten in Java geschrieben. Eher C++ würde ich fast behaupten. Es ist allgemein schwer mit schönen Rendering / Animation 60fps mit einem java renderer zu schaffen. Da sind native Sache doch um einiges performanter.
Also wir schreiben alles nur noch mit GWT haben noch ein paar alte SWING Programme allerdings sind die um einiges mühsamer zu pflegen.
Hat auch den vorteil das wir keine jre’s an user verteilen müssen und keinen updater damit das Programm aktuell gehalten wird.
welche ‚so kritschen GUIs‘ sind denn das Nebenthema mit 60 FPS?
eine 3D-Engine im Hintergrund werden die wenigsten haben und allein ein solches Vollast-Vehikel wie moderne 3D-Spiele ist eine Ausrede für C++,
ansonsten spielt C++ keine Rolle in seriöser Programmierung, falls nicht Altlast-Vorgabe, auf soviel sollte doch zu einigen sein 
nein, GUIs sind simple Anwendungen mit Buttons & Tabellen, heute nicht viel anders als in den 80ern in ersten Windows-Versionen & Co.,
Geschwindigkeit für normale Clients damals wie heute kein Thema (außer Dauer der Aktionen, die im Hintergrund angestoßen werden),
Java als zivilisierte Hochsprache problemlos einsetzbar, von AWT in 1.0 bis zu den neuesten Varianten, Geschwindigkeit in Reaktion auf einen Button-Klick nie die Frage,
hinsichtlich Browser meinte Bleiglanz doch sicherlich dass man manchmal schnell 5 Dinge hintereinander anklicken möchte,
ohne zwischendurch auf Netzwerkrequests oder Browser-Neuaufbau der Seite zu warten,
das ist nämlich eine echte Hürde, ganz andere Dimension als mikroskopische Geschwindigkeitsunterschiede zwischen Programmiersprachen
[quote=SlaterB]hinsichtlich Browser meinte Bleiglanz doch sicherlich dass man manchmal schnell 5 Dinge hintereinander anklicken möchte,
ohne zwischendurch auf Netzwerkrequests oder Browser-Neuaufbau der Seite zu warten,[/quote]
Sorry, zur Klarstellung: ich meinte kein 60fps Spiel oder so was - sondern wirklich nur den Bildschrimaufbau, wenn man
Da passiert auch was am Bildschirm, und zwar bei fat GUIs oft recht schnell…
[QUOTE=SlaterB]welche ‚so kritschen GUIs‘ sind denn das Nebenthema mit 60 FPS?
eine 3D-Engine im Hintergrund werden die wenigsten haben und allein ein solches Vollast-Vehikel wie moderne 3D-Spiele ist eine Ausrede für C++,
ansonsten spielt C++ keine Rolle in seriöser Programmierung, falls nicht Altlast-Vorgabe, auf soviel sollte doch zu einigen sein
[/QUOTE]
Ka mit 60 FPS war Bleiglanz Einwurf.
Und das mit C++ würde ich nicht so laut sagen, gibt doch schon einige „Die Hard“ C++er ^^
Buttons, Tabellen, DropDown Felder kann man genauso gut im Browser machen und hat dann keine Sorgen mit Verteilen der Anwendung. Ein wirklicher Vorteil von JavaFx gegenüber GWT habe ich bis jetzt noch nicht gehört.
Das einzige wirkliche Problem von Browsern ist die unterschiedliche Interpretation von CSS Werten. Da gibts schon ein paar Kniffe die man wissen muss.
Edit:
Ein wirkliches Problem von GWT ist seit 2.7 mit dem Super Dev mode bekannt. Das Debugging wird so zur Hölle.
Timothy_Truckle oder einer der anderen Antworter könnt ihr mir vllt ein paar gute quellen (Bücher, Tutorials…) zu MVC und XML nennen, hab da nicht viel gefunden. Ich hab mir 4 JavaFx Bücher geholt und dort ist nie die rede von MVC oder Fxml. Und ist es Üblich in der Praxis Fxml selbst zu schreiben oder benutzt man da Scene Builder?
Der Scene Builder generiert dir das fxml. In dieses injectest du deinen Java Controller der Zugriff auf die XML Attribute hat (gelandet mittels der ID die du einer Node mit dem Scene Builder gibst)
So hast du effektiv die GUI Logik mit der Businesslogik getrennt.
Für ein Tutorial hat mir das hier gereicht:
JavaFX 8 Tutorial | code.makery.ch
Bücher sind mir persönlich zu überladen.
Ach was. Tabellen mit 40 Spalten und 10000 Zeilen, DropDown mit großen Auswahllisten etc. Der ständige Round-Trip zum Server in Verbindung mit dem viel zu langsamen DOM-Ungetüm verhindert oft das schnelle reagieren einer JS-Single-Page App (vom Seitenwechsel bei einer Multi-Page reden wir mal gar nicht). Und den lokalen Zustand sicher festzuhalten ist a) in Javascript nicht ganz einfach und b) langsamer, ruckliger und wegen „rechte Maustaste - neuer Tab“ auch extrem komplex und verwirrend.
Mir ist auch klar, dass JS+Framework in vielen Bereichen einen Haufen Vorteile haben (oft aber nur für Entwicklung, Deployment, laufenden Betrieb und NICHT für den Anwender)
Bei vielen Anwendungen (mehr Lesen als Schreiben & Tippen) ist das sicher machbar, auch mit guter Usability; aber einfach kategorisch zu sagen, dass man JavaFX nicht braucht - das kann so nicht stimmen
[QUOTE=Prototype]Der Scene Builder generiert dir das fxml. In dieses injectest du deinen Java Controller der Zugriff auf die XML Attribute hat (gelandet mittels der ID die du einer Node mit dem Scene Builder gibst)
So hast du effektiv die GUI Logik mit der Businesslogik getrennt.
Für ein Tutorial hat mir das hier gereicht:
JavaFX 8 Tutorial | code.makery.ch
Bücher sind mir persönlich zu überladen.[/QUOTE]
Ich weiß dass der Secene Builder die Fxml generiert, hab schon schon ein wenig damit gearbeitet. Meine Frage ist ob man es auch so in Projekten macht die Fxml durch den Scene Builder generieren lässt oder man es selbst in fxml schreibt.
Das Tutorial hab ich schon durchgearbeitet gibt es noch andere Quellen?
Das original Tutorial bei Oracle fand ich nicht schlecht, wenn auch etwas mühsam.
Client Technologies: Java Platform, Standard Edition (Java SE) 8 Release 8
Danke Bleiglanz werd ich mal durcharbeiten.
Ein problem hab ich noch und zwar, wenn ich eine Fxml Datei per SceneBuilder öffnen will wird mir der SceneBuilder nicht als Programm angezeigt ich hab den Pfad bei Javafx zur exe. datei gesetzt, ich muss immer zu externer Software gehen und dann nach der exe browsen, dann gehts. Ich benutzt JKD 8, neueste Version Luna und SeceneBuilder 8.0 hat nocht jemand das gleiche problem oder kennt eine Lösung?
Wenn du willst kannst du auch selbst das fxml schreiben so schwer ist das nicht. Kannst du dir ja anschauen. Allerdings kannst du nicht mehr machen als mit dem Builder auch, deshalb ist das ganze weniger sinnvoll.
Ach was. Tabellen mit 40 Spalten und 10000 Zeilen, DropDown mit großen Auswahllisten etc. Der ständige Round-Trip zum Server in Verbindung mit dem viel zu langsamen DOM-Ungetüm verhindert oft das schnelle reagieren einer JS-Single-Page App
Kann ich so nicht unterschreiben. Habe schon mind. eine wesentlich komplexere Anwendung geschrieben (mit mehreren Tabellen 200 Spalten und 10-15 Zeilen und davon 5 auf einer Seite). Läuft sehr flüssig in chrome und FireFox zumindest.
Edit:
Wenn du windows hast kannst du doch einfach den Builder als default für dieses Dateiformat angeben. (Immer öffnen mit)
Ich öffne die Datei aber immer über Eclipse, wenn ich in Windows die Datei als default einstelle, wird die Datei dann wenn ich sie Über eclipse öffne auch per SceneBuilder geöffnet?
*** Edit ***
habs probiert, geht leider nicht.
*** Edit ***
bringts was, wenn ich mir die SeceneBuilder jar lade? und wo muss ich die einfügen?
*** Edit ***
Ok danke problem gelöst.
Soweit ich das verstanden hatte wollte Oracle damit Java ausweiten.
MVC ist schön und gut und hält den Code schön sauber, aber theoretisch kann so eine FXML Datei auch auf Smartphones, Tablets und jedem anderen elektronischen Gerät “interpretiert” werden inklusive Webanwendungen.
Swing ist halt Hardgecoded und auch nicht gerade unbedingt 100%ig plattformunabhängig geschweige denn für andere Geräte außer PCs geeignet.
Habe die Entwicklung danach nicht mehr verfolgt, dachte aber die wollten mit einem eigenen Betriebssystem wieder einsteigen… naja auch egal, JavaFX ist toll.
Hinzu ist Swing mittlerweile zu einem kompletten Müllhaufen geworfen. Wenn man sich anschaut was dort teilweise für Müll reingeschrieben wurde, z.B. um im nachhinein noch ein Interface in ein bestehendes Konstrukt hinzuzufügen und dann steht da haufenweise Zeugs wie “A interfaceof B”… naja egal.
Und ja bei JavaFX verwendet man normalerweise den SceneBuilder bzw. allgemein einen DragNDrop-Editor. Das ist eben einer der Vorteile so eine XML-Struktur zu verwenden und eigentlich ist es auch völlig wurscht denn von all dem was der SceneBuilder generiert landet garnichts in deinem Code!
GUIs per WYSIWYG-Tools zu erstellen ist normalerweise sehr verpöhnt, da der Swing-Code der am Ende rauskommt praktisch unleserlich ist und sich über die Zeit gerne mal Redundanzen oder Fehler einschleichen.
Per FXML spielt all das aber überhaupt keine Rolle mehr, entsprechend hat Oracle auch den offiziellen SceneBuilder herausgebracht.
Wenn man dann noch mit CSS umgehen kann wird die Sache noch viel interessanter. Schatten-, Glow- und andere Effekte, Farben, Formen und so weiter macht JavaFX weitaus mächtiger als Swing oder die meisten anderen GUI-Bibliotheken.
Einziges Problem ist die Performance. An JavaFX wird immernoch entwickelt aber im Moment ist es ein sehr teures Unterfangen. Insbesondere auch weil man sehr leicht in ein paar Sekunden tolle Effekte kreieren kann die aber umso mehr auf den RAM und CPU gehen. Aber dann wiederum ist es nur eine GUI-Anwendung, mehr als schön aussehen braucht sie eigentlich nicht.
Trotzdem wäre ein Excel Klon z.B. im Moment nicht möglich, denn im Moment wird per JavaFX alles gezeichnet was existiert egal ob sichtbar oder nicht.
NUR eine GUI-Anwendung? Hoffentlich werden damit keine Atomkraftwerke oder Herzoperationen verwaltet
Aber du hast Recht: Die Anwender haben ja meist keine Ahnung von „eleganter Programmierung“, „Frameworks“, „Datenbanken“ oder „Databindig“, für die ist eine Anwendung gut, wenn sie gut aussieht und sich gut anfühlt (Usability). Das Aussehen ist da tatsächlich alles.