Swing, SWT oder Java FX

[javahoush]

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]

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]

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]

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]

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

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

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]

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]

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]

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.

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]

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]

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]

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]

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]

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]

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.

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]

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]

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:
Do you know more about the JavaFX-license?
It seems, that it is not allowed to spread the JavaFX-runtime.
If you download the SDK, you have only _one_ license for _one_ computer. It is not allowed to integrate it in its own programs and publish it, for example.
So, creating JavaFX-standalone programs is senceless.
And if you create internet programs with webstart, then you must integrate the link to Suns JavaFX runtime, that the user downloads it direct from Suns side.
But JavaFX changed in 1.2 its binary-format. That means, if you have a online-program, and there comes a new JavaFX version out, your program will no longer run.

Have also a look at
JavaFX - Wikipedia, the free encyclopedia

I have also already written in the forum at
java.net Forums : What I don't like on JavaFX ...
there are good answeres. But not related to the license.

It is possible, that the runtime of JavaFX is part of the compiler-project:
http://kenai.com/projects/openjfx-compiler/sources/marina-master/show
it seems, that all files are there (I am not sure). But the problem is, that - unlike OpenJDK - there all the files are under the GPL _without_ GNU Classpath exception !!

Do you know more about the license?
If it will in any time be usable.

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?
If I would have the right to spread the runtime, I could publish it on my own side WITH JavaFX apps. But so, I must confiding, that dl.javafx.com is everytime reachable.

I think, that the license is at the moment the main problem of JavaFX.

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]

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

 

[Gast2]

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]

Ä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]

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]

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]

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]

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]

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]

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.