# Swing, SWT oder Java FX



## javahoush (21. Jul 2009)

Hallo,

nein, nein ich will keine grundsatz, Kriegsdiskussion um diese beiden GUI-Toolkits/Bibs eröffnen.

Nur eine kleine Frage:
Wie steht es derzeit um SWT? Mein Wissensstand ist, dass SWT für Eclipse verwendet wird und sich scheinbar dort auch bewährt hat. nun gibt es aber seit ca. 2005 kaum neue Literatur zu SWT und ich frage mich, ob man nicht einen "strategischen" Fehler macht jetzt auf SWT zu gehen.
Wie ist da der Zusammenhang zu Java FX?

Wäre im Grunde dankbar für einen vogelperspektivischen update.

gruß,
harald


----------



## byte (21. Jul 2009)

Literatur zu dem Thema ist auch schwierig weil sich SWT bzw. Eclipse RCP ja dauernd weiterentwickelt. Jedes Jahr kommt ein neuer Major Release raus. Also könnte man jedes Jahr ein neues Buch schreiben.
Aber es gibt auch durchaus einige aktuelle Bücher zu dem Thema.


Auf jeden Fall kann man sagen, dass sich bei Eclipse RCP / SWT deutlich mehr tut als bei Java Swing. Wenn ich gucke, was es mittlerweile teilweise für Web UI Frameworks gibt und das mit Swing vergleiche, dann ist Swing einfach hoffnungslos veraltet. Und dieses Swing Application Framework, was als JSR für Java 7 geplant war, ist jetzt wohl auch schon länger eingefroren.

Ich würde heute nicht mehr auf Swing als Frontend setzen, wenn ich vorhabe, einen Client mit modernem Ui zu bauen. Da würde ich doch eher auf SWT gehen oder gleich ne Webanwendung bauen.


----------



## ModellbahnerTT (21. Jul 2009)

Also wenn du nicht gerade das massive Eclipse Produkt Portfolio brauchst, dann würd ich SWT nichtmal mit der Kneifzange anfassen, dafür geht die Entwicklung in SWT einfach zu langsam. Und an SWT selbst wie auch an Swing  wurde auch in den letzten Jahren keine großen Änderungen vorgenommen.


----------



## byte (21. Jul 2009)

Klar wurde SWT in den letzten Jahren weiterentwickelt! Da hat sich ne Menge getan:

2009: Eclipse 3.5 Milestone New and Noteworthy Items - SWT
2009: Eclipse 3.4 Milestone New and Noteworthy Items - SWT
2008: Eclipse 3.3 Milestone New and Noteworthy Items - SWT
2007: Eclipse 3.2 Milestone New and Noteworthy Items - SWT
2006: Eclipse 3.1 Milestone New and Noteworthy Items - SWT
2005: Eclipse 3.0 Milestone New and Noteworthy Items - SWT


----------



## Gast2 (21. Jul 2009)

javahoush hat gesagt.:


> Hallo,
> 
> nein, nein ich will keine grundsatz, Kriegsdiskussion um diese beiden GUI-Toolkits/Bibs eröffnen.
> 
> ...



Eclipse RCP Sachen gibts genügend im Netz...



ModellbahnerTT hat gesagt.:


> Also wenn du nicht gerade das massive Eclipse Produkt Portfolio brauchst, dann würd ich SWT nichtmal mit der Kneifzange anfassen, dafür geht die Entwicklung in SWT einfach zu langsam. Und an SWT selbst wie auch an Swing  wurde auch in den letzten Jahren keine großen Änderungen vorgenommen.



Wie kommst du darauf, dass ich bei SWT nichts tut? Kannst du das belegen oder ist nur eine Vermutung/Behauptung von dir?


----------



## theuserbl (21. Jul 2009)

Also wenn man richtige plattformunabhängigkeit haben will, gibt es eigentlich nur Swing.

Bei Swing-Anwendungen läuft es auf jedem Betriesbssystem und jeder Hardware mit einem (aktuellen) Java.
Bei SWT benötigt man Java _und_ SWT.
Und das beides für eine beliebige Plattform existiert ist unwahrscheinlicher als daß nur Java existiert.

Außerdem stellt sich die Frage wie es mit SWT gehandhabt wird:
Wird es ins System installiert (wie Java) oder liegt es dem Programm hinterher als zusätzliche Bibliothek bei?
Letzteres würde bedeuten, daß jedes SWT-Programm mit seinem eigenen SWT kommt und bläht das eigene Programm unnötig auf.

Auch haben viel weniger Personen SWT bei sich installiert als Java. Also sollte man seinem Programm für die unterschiedlichen Plattformen die nativen SWT-Bibliotheken beifügen.
In dem Fall würde ich dann wiederum C++/Qt bevorzugen, wenn ich schon jede Plattform mit den eigenen Binaries versorgen muß.


----------



## theuserbl (21. Jul 2009)

javahoush hat gesagt.:


> Wie ist da der Zusammenhang zu Java FX?



JavaFX hat ein "leichtes" Lizenzproblem.
Selbst die Sun-Entwickler sagen, daß es eigentlich für RIAs (also für Internetanwendungen) entwickelt wurde.

Die Lizenz erlaubt es JavaFX mit seiner Runtime zu verwenden. Jedoch darf man es nicht verbreiten/weitergeben.
Jeder Anwender muß sich die JavaFX-Runtime selber von Suns Webseite runterladen.

Bei RIAs wird das Problem dadurch gemindert, indem das eigene in JavaFX geschriebene Programm vom Anwender runtergeladen wird und mit Hilfe der Webstart-Technik ebanfalls die entsprechende JavaFX-Runtime von Suns Server geladen wird.
Ist Suns Server jedoch down, dann laufen die ganzen JavaFX-Anwendungen im Internet nicht mehr.
Und für lokale Anwendungen ist es halt - von der Lizenz her - nicht entwicklelt worden.


----------



## ModellbahnerTT (21. Jul 2009)

byto hat gesagt.:


> Klar wurde SWT in den letzten Jahren weiterentwickelt! Da hat sich ne Menge getan:


Klar, aber das sind doch sogut wie alles nur minor changes, sowas find ich auch in Swing. Aber API-mäßig ist SWT genauso 'final' wie Swing.



theuserbl hat gesagt.:


> Auch haben viel weniger Personen SWT bei sich installiert als Java. Also sollte man seinem Programm für die unterschiedlichen Plattformen die nativen SWT-Bibliotheken beifügen.
> In dem Fall würde ich dann wiederum C++/Qt bevorzugen, wenn ich schon jede Plattform mit den eigenen Binaries versorgen muß.


Ne, du brauchst nur die swt.jar immer mit auszuliefern, den Rest erledigt SWT eigentlich von selbst. Der Ganze Heckmeck mit den nativen Bibliotheken wird m.M. nach eh immer zu ernst genommen, am Ende mach ich ja eh verschiedene Launcher für die verschiedenen Plattformen, das wär dann auch nicht mehr das Problem.


----------



## theuserbl (21. Jul 2009)

ModellbahnerTT hat gesagt.:


> Ne, du brauchst nur die swt.jar immer mit auszuliefern, den Rest erledigt SWT eigentlich von selbst.


Wie das denn? Indem es die nativen Blilotheken von alleine aus dem Internet runterläd?
Dann braucht der Endanwender auf jeden Fall einen Internetanschluß.
Ich habe z.B. zu Hause _keinen_ Internetanschluß. Wenn ich vom Internetacafé heruntergeladene Programme zu Hause nutzen möchte, transportiere ich sie mit dem USB-Stick.



> Der Ganze Heckmeck mit den nativen Bibliotheken wird m.M. nach eh immer zu ernst genommen, am Ende mach ich ja eh verschiedene Launcher für die verschiedenen Plattformen, das wär dann auch nicht mehr das Problem.


Aha, auch noch verschiedene Launcher?
Ich kenne es bisher nur, daß es entweder für Windows einen eigenen Launcher gibt und für Unixe ein Shell-Skript oder aber das Programm als platformübergreifendes Jar einherkommt.
Wenn Du jedoch schon für jede Plattform einen eigenen Launcher schreibst, dann kann man wirklich schon wieder an die C++/Qt Alternative denken.


----------



## Ebenius (21. Jul 2009)

Wie ist das eigentlich in diesem Kontext mit unsignierten Webstart-Anwendungen? Swing-Anwendungen kann ich so verteilen, bei SWT wird das schwer bis unmöglich, oder?

Ebenius


----------



## byte (21. Jul 2009)

Auf Basis von SWT programmierte Clients sind ja idR mit Eclipse RCP entwickelt. Das Projekt basiert also auf Eclipse Equinox (OSGi). Das bedeutet, man exportiert am Ende lediglich das Produkt und die Eclipse IDE generiert die Binaries mit allen Abhängigkeiten samt EXE (unter Windows) automatisch.

Man braucht dann nur noch dieses Verzeichnis auszuliefern und es läuft auf jedem Zielrechner der Plattform, wenn dort ein JRE installiert ist. Wie das mit Suns Webstart funktioniert, weiss ich nicht. Wir haben in der Firma einen eigenen Webstarter, ein Java Applet, das die Sourcen des Eclipse Products runterlädt und startet.


----------



## Ebenius (21. Jul 2009)

Gut, auf dem Weg wird nichts ohne Signatur. Wollte ich nur mal wissen; vielleicht gibt's da was anderes hübsches...

Grüße, Ebenius


----------



## Wildcard (21. Jul 2009)

SWT Anwendungen lassen sich per Webstart verteilen (auch wenn ich es selbst noch nie gemacht habe).


> Also wenn du nicht gerade das massive Eclipse Produkt Portfolio brauchst, dann würd ich SWT nichtmal mit der Kneifzange anfassen, dafür geht die Entwicklung in SWT einfach zu langsam. Und an SWT selbst wie auch an Swing wurde auch in den letzten Jahren keine großen Änderungen vorgenommen.


Was soll denn zu langsam heißen? Für ansprechende SWT GUIs braucht man dank JFace wesentlich weniger Code als für Swing Anwendungen. Sowas wie Eclipse Forms mit Swing umzusetzen ist auch alles andere als witzig und das SWT/JFace Databinding ist das bessere.


----------



## EgonOlsen (21. Jul 2009)

theuserbl hat gesagt.:


> JavaFX hat ein "leichtes" Lizenzproblem.
> Selbst die Sun-Entwickler sagen, daß es eigentlich für RIAs (also für Internetanwendungen) entwickelt wurde.
> 
> Die Lizenz erlaubt es JavaFX mit seiner Runtime zu verwenden. Jedoch darf man es nicht verbreiten/weitergeben.
> ...


Das wusste ich noch gar nicht. Muss man sich bei Sun eigentlich das Gehirn rausnehmen lassen, bevor man ein neues Produkt bzw. dessen Marketing entwirft? Was soll diese Einschränkung? Will man den Erfolg mit allen Mitteln verhindern (wird man IMHO nicht müssen, es wird keiner werden, aber das ist eine andere Sache...)?


----------



## theuserbl (21. Jul 2009)

EgonOlsen hat gesagt.:


> Das wusste ich noch gar nicht. Muss man sich bei Sun eigentlich das Gehirn rausnehmen lassen, bevor man ein neues Produkt bzw. dessen Marketing entwirft? Was soll diese Einschränkung? Will man den Erfolg mit allen Mitteln verhindern (wird man IMHO nicht müssen, es wird keiner werden, aber das ist eine andere Sache...)?



Einfach unter JavaFX.com einer der Webstart-Anwendungen ausführen. Beim ersten Starrt kommt die Endbenutzerlizenz, bei der ua. drinsteht:


> 5.	Beschränkungen
> (a) Die Softwarekopien, die Ihnen gemäß dieser Vereinbarung von Sun zur Verfügung gestellt werden, sind lizenzierte, aber keine verkauften Kopien. Sun behält sich alle Rechte vor, die nicht gewährt wurden. (b) Sie dürfen eine einzelne Kopie der Software für Archivierungszwecke erstellen – es ist Ihnen jedoch nicht gestattet, die Software für andere Zwecke zu kopieren, zu modifizieren oder zu verteilen.



Als Beispiel.
Dadrüber gab es auch schon einige Diskussionen.


----------



## theuserbl (21. Jul 2009)

Hier eine etwas detailiertere Antwort zu JavaFX.

Alles hatte mit diesem Heise-Post angefangen. Wodrauf eine Diskussion zwischen ihm und mir folgte.

Um dem nachzugehen, jhatte ich unter anderem dem JavaFX-Entwickler Joshy in sein Bloggeschrieben.

Für Leute die nicht nachgucken wollen:

Ich schrieb


> Nice arcticle.
> But I am missing a Webstart-program of the first screenshot (that with the nice GUI).
> 
> But to a nother subject:
> ...



Joshy antwortete


> JavaFX apps are distributed as applets or webstart, so the correct runtime will be auto-downloaded from dl.javafx.com and cached. The runtime is versioned, so you never have to worry about a new update breaking your old app. If you wrote an app against the 1.1 runtime it will always run against the 1.1 runtime, even if we've released JavaFX 30 by then.



Wodrauf ich schrieb


> @joshy:
> And what is with desktop-apps without internet-connection?
> And Larry Ellison have had the idea to port OpenOffice.org to JavaFX.
> And what is, if dl.javafx.com is down?
> ...



Wodrauf Joshy nicht mehr geantwortet hatte.
Er hatte es aber gelesen, weil ich auch hier auf den neuen Eintrag hinwies.

Naja, ist halt ein Theme, daß Sun unter den Teppich kehrt.


----------



## byte (22. Jul 2009)

Äh, ist das nicht das selbe wie mit der JRE? Die darf man doch imo auch nicht mit der eigenen Anwendung verteilen.


----------



## Gast2 (22. Jul 2009)

Ebenius hat gesagt.:


> Gut, auf dem Weg wird nichts ohne Signatur. Wollte ich nur mal wissen; vielleicht gibt's da was anderes hübsches...
> 
> Grüße, Ebenius



Webstart mit Eclipse RCP(> Version 3.2.2) klappt wunderbar.


----------



## Marvelman (13. Aug 2009)

> Äh, ist das nicht das selbe wie mit der JRE? Die darf man doch imo auch nicht mit der eigenen Anwendung verteilen.


Nun genau genommen ist Webstart so wie ich es auf JavaFX | Rich Internet Applications Development | RIAs Java FX verstanden habe ein Teil der JRE.
Oder noch besser ausgedrückt hast du aktuelle JRE runtergeladen kannst du ohne Probleme JavaFx Anwendungen im Internet oder bei dir auf den Desktop starten, jedenfalls war das bei mir so.

Ich hab mich ein wenig daran probiert es gibt 3 Arten eine JavaFx Anwendung zu starten.
1. Ganz normal mit Mausklick auf dem Desktop(Icon)
2. Mit Webstart das dafür gedacht ist sich die Anwendung aus den Internet herunterzuladen und auf den Desktop  als Task auszuführen.
3. Im Browser ausführen mittels eine Script(seit V1.2)
Wenn man 2 und 3 komponiert kann man das laufende Programm aus den Browser auf den Desktop als Task ziehen und es kommt zu einen kleinen AHA Erlebnis    

Übrigens in JavaFx kann man alles benutzen was man von Java kennt, das ganze Framework von Java ist mit enthalten. Ich denke Java 7 wird das letzte Java sein und dann wird wahrscheinlich der Zug voll auf JavaFX umschwenken 

Es ist richtig das Sun/Orakle die Rechte an der JRE(Ausnahme das Framework) hat das gilt für Java wie JavaFX, was allerdings dem positiv entgegensteht ist das Java und JavaFx als Sprache Open Source sind. Was unter den 3 mächtigen RIA´s glaube ich JavaFx das einzige macht was einiger massen Open Source ist.

Was mich zur der Frage führt für welchen Einsatzgebiet sind RIA´s gut?(Rich Internet Application)
JavaFX(ähnliches Level wie PHP) hat einen stark vereinfachten Syntax gegenüber Java, hat eine sehr gute Framework zur Erzeugung von grafischen Webanwendungen, aber trotzdem finde ich nichts über Client-Server Beziehungen aufJavaFX | Rich Internet Applications Development | RIAs Java FX oder auf Sun Microsystems
Nur tote Links mit Google


----------



## Noctarius (13. Aug 2009)

Ich persönlich glaube nicht, dass Java 7 die letzte JRE Version sein wird, weil:
1. viele Features die in Java 7 kommen sollten aus Zeitmangel wieder ausgeplant wurden
2. Java eine typisierte Programmiersprache und keine Scriptsprache, wie JavaFX, ist
3. JavaFX viel zu sehr nach JavaScript aussieht, als das sich Jemand damit anfreunden könnte, der JavaScript verachtet


----------



## Marvelman (13. Aug 2009)

Kommt darauf an deswegen "wahrscheinlich". Ehrlich gesagt mag ich JavaScript/Ajax kein bisschen. Eigentlich kam ich auf JavaFx , weil  ich mir überlegte was ich  für ein Webprojekt das ich angezielt habe bräuchte. Die Liste war dann HTML, CSS, PHP ,JavaScript ,Java , nachdem ich mit etwa 5 Minuten ein JavaScript Tutorial angesehen hatte was ich als einziges in dieser Liste nicht kann, kam mir die Idee das muss doch anders gehen. 
Theoretisch versprechen RIA´s da genau Abhilfe aber bis jetzt sieht es nicht danach aus, b.z.w. ich muss noch ein wenig tiefer bohren, glaube ich.

Das ist so ein wenig schwabbelig weil teilweise in der Werbung auf JavaFX | Rich Internet Applications Development | RIAs Java FX behauptet wird das Sun mit JavaFx auf den Desktop und in Embedded Systems Markt vorstoßen will, aber anderseits RIA´s ans Internet gebunden sind, da mag es eine Schnittmenge  irgendwo geben aber da scheint den Zug links und rechts gleichzeitig vom Bahnhof abfahren zu fahren.:bahnhof:

So kann ich kein definitives Ja oder Nein geben zur Zukunft von JavaFx  b.z.w Java geben. Diese Verwirrtheit war mit ein Grund  für mein vorherigen Post, der andere die Tatsache das trotz Suchfunktion man nicht sehr viele Infos zu JavaFx in den Forum findet obwohl es zur Java Famile gehört, Syntax mag zwar anders sein, aber sehr viel von Java unter der Haupe.:rtfm:


----------



## Wildcard (13. Aug 2009)

Für RIAs sehe ich großes Potential für Eclipse e4. Schon jetzt lassen sich in dieser Richtung beeindruckende Ergebnisse mit Eclipse RAP erziehlen, aber mit e4 dürften die neuen Eclipse Fähigkeiten deutlich bekannter werden.


----------



## byte (13. Aug 2009)

Ich wage zu bezweifeln, dass JavaFX sich als RIA im Internet wirklich durchsetzt. Flash gibts auch schon seit zig Jahren. Es ist zwar weit verbreitet, aber trotzdem werden heute die wenigsten Webseiten ausschließlich in Flash geschrieben.

Im Grunde gibts RIA ja in zwei Geschmacksrichtungen: Da wären auf der einen Seiten Flash, JavaFX, Silverlight, für die man alle Browser Plugins benötigt. Und dann wären da die RIA Frameworks, die einzig und allein mit HTML, CSS und JS auskommen, also keine Browsererweiterungen benötigen.

Meiner Meinung nach werden letztere das Rennen machen, weil sie auf offenen Standards basieren statt auf proprietären Lösungen.


----------



## Wildcard (13. Aug 2009)

Sehe ich genauso. Die Clientseitigen Frameworks haben ihre Nische, scheitern aber schon an bei der Serverkommunikation. Ausserdem ist die Usablility in meinen Augen eine Katastrophe. Flash frisst geradezu CPU (besonders auf Linux), JavaFX ist mir noch nichts untergekommen, krankt aber schon an der Startup-Time der VM (auch wenn das ja besser werden soll) und SIlverlight... nein Danke.


----------



## byte (13. Aug 2009)

Gute Punkte Wildcard. Desweiteren werden die JS-Engines der großen Browser immer besser und schneller (JIT-Compiling usw). Und die großen Player (siehe Google) setzen bisher im Grunde alle auf AJAX basierte Frameworks, siehe z.B. Google Wave mit GWT.


----------

