Zitat von
r_kerber:
Trotzdem fühlen sich SWT-Anwendungen bei der Bedienung anders als native Windows- oder .Net-Anwendungen. Und bei SWT hast Du meine Aussage bestätigt. Wenn die SWT nämlich gar nicht oder nicht in der erforderlichen Version vorliegt, dann ist eine 1:1-Lauffähigkeit eben nicht gewährleistet.
Hi,
möchte mich auch mal zu diesem (ewig gleichen?) Thema äußern. Was SWT angeht, so kann ich nicht pauschal sagen, dass es wie ein Fremdkörper wirkt. Unter Linux und unter Windows habe ich häufiger mit Eclipse zu tun. Dort starte ich eine kompilierte Datei (also eine Exe unter Windows) und die läuft wie jede andere
IDE auch. Sicherlich nimmt die sich etwas Zeit beim Start, bei VS oder gar Delphi sieht das aber mal überhaupt nicht anders an.
Wenn man Java nicht mag, dann ist das ok. Aber vielleicht sollte man auch mal ehrlich sein, ob man nicht den Fremndkörper-Eindruck sucht. Möchte ich etwas negatives finden, dann brauch ich nicht lange, egal ob es .Net, C, C++, Haskell, Delphi, Java oder eine andere Sprache sein soll.
Was die GUIs in Java angeht, so gibt es eine ganze Menge von Möglichkeiten. Neben dem benannten SWT und Swing kann man z.B. auch auf Qt zurückgreifen. Qt für Java greift dabei auf das JNI zurück, man hat es hier also mit nativen, dyn. gelinkten Bibliotheken zu tun. Das Aussehen von Qt - Anwendungen dürfte jeder kennen, auch die Perfomance ist (trotz Kapselung) mehr als ausreichend. Natürlich kann man hier wieder einwerfen, dass "Write once, run everywhere" nur ein Marketing Spruch ist (wer ist jetzt wirklich überrascht?!). Denn auch wenn für die Verwendung von SWT oder Qt jeweils eine Implementierung für die Zielplattform vorliegen muss, das Gleiche gilt doch schon für die VM. Ich sehe an der Stelle mal von eine Java - konformen Architektur ab, welche Java Byte Code direkt ausführen kann (dürfte ja wohl kaum im Einsatz sein). Auch wenn eine JVM für viele Plattformen verfügbar ist, für alle wird das kaum gelten.
Schau ich nun aber auf die relevanten Plattformen und hätte gerne eine Anwendung die unter MacOS, Linux oder Windows gleichermassen läuft, dann ist Java nun mal vorne bei. Natürlich werden viele (auch interessante und wichtige) weitere Plattformen unterstützt. Insbesondere darf man nicht den Markt für Großunternehmen außer Acht lassen. Gerade im Bereich der Server-Software wird häufig eine Java EE Basis verwendet. Ich hatte neulich erst ein Gespräch mit Oracle, bei denen mir die Möglichkeiten ihrer Anwendungen erklärt wurden und die waren Java basiert (und beeindruckend!). Für das konkrete Produkt beträgt die Mindestabnahme 500 Lizenzen und das sicherlich nicht, weil man danach keine Kunden mehr findet und so das gesamte Geld mit einem Verkauf reinholen möchte.
Natürlich hat Java genauso Einschränkungen wie es sie in jeder anderen Sprache gibt. Zum Beispiel kann ich in Java nicht funktional Arbeiten und Closures sind auch für Java 7 nicht geplant. Aber es gibt auch Felder in denen man sehr komfortabel mit dieser Sprache arbeiten kann. Dass .net eine ernste Konkurrenz ist steht ausser Frage, aber man sollte nicht die Rechtfertigung einer Sprache anzweifeln. Wenn sie die ihre verliert, dann wird sie einfach nicht mehr verwendet.
Was man nicht vergessen sollte ist immer, dass Java so alt ist wie Delphi, beide kommen aus den 80er Jahren. Natürlich veraltet eine Sprache in dieser Zeit und nicht immer ist die Neustrukturierung gelungen (und das gilt für alle Sprachen mit dem Alter).
Das man Java hier aber noch mit den recht jungen Konzepten von .net messen kann oder sogar muss zeigt hier schon, dass die Jungs von SUN nicht alles falsch gemacht haben. Wichtig ist und bleibt aber, dass hier überhaupt ein Konkurrenzkampf entsteht. Ich denke nicht, dass .Net so gut wäre, wenn man nicht bereits aus den Fehlern und Schwächen von Java gelernt hätte. Anslog sieht es bei der Evolution von Java aus, hier fließt sicherlich einiges ein, was andere Sprachen besser machen.
Und wenn man nun die Zeit vor .net betrachtet, dann brachte Java einfach einen Ansatz, der ein deutliches Plus an Sicherheit bot und bietet. Managed Code hat einfach den Vorteil, dass Speicherlecks nicht möglich sind. Was man aber auch betrachten sollte ist die starke Typsicherheit von Java, man vergleiche sie mit C oder C++ Code, welcher zwar perfomanter ist, Fehler aber leichter möglich macht. Anders als Delphi ist Java zudem sehr strikt in der Objekt Orientierung (geht aber durch die primitiven Typen nicht soweit wie z.B. SmallTalk).
Und gerade mit Java EE hat sich ein mächtiges Framework etabliert, dass einfach viele gute Ansätze für wirklich hohe Ansprüche bietet. Von Konzepten für's einfache Skalieren und eine gute Lastverteilung, über Redundanz bis hin zur hohen Sicherheit und insbesondere einem ausgereiften Transaktionsmodell wird einiges geboten. Und schaut man sich den Zugriff auf Datenbanken unter Verwendung von Bohnen (Java EE Beans) an, dann ist das um einiges langsamer als ein Zugriff über JDBC, dennoch kommt es in dem Segment überhaupt nicht auf die Perfomance an (also sicherlich auch, aber andere Faktoren überwiegen deutlich). So wäre in einer Bank eine kleine Verzögerung tragbar, ein Verlust von Daten (und damit von Geld) hingegen eine Katastrophe.
Sicherlich ist auch hier Java nicht perfekt, aber .net noch lange keine ausgereifte Konkurrenz. Immerhin konnte Java hier schon einiges an Entwicklung mitmachen und auch aus früheren Problemen lernen. Hauptproblem der Java EE ist und bleibt die hohe Komplexität (mit der jedoch auch ein hoher Nutzer einher geht). Hier existiert halt schon eine Lösung (ohne Frage ist mit genug Zeit ähnliches auch in .net verfügbar und sicherlich auch in C, C++, Haskell, ... realisierbar). Die etablierten Lösungen haben jedoch den Vorteil, dass man bereits mit ihnen vertraut ist, man kennt die Stärken und Schwächen, es gibt genug Personal mit ausreichendem Knowhow, es gibt fertige Workarounds und jede Menge nutzbarer Komponenten.
Deshalb möchte ich auch noch mal klar sagen, dass sicherlich der Einsatz einer bestimmten Sprache auch eine politische Entscheidung sein kann, viel wichtiger sind aber in der Regel sehr weitgehende (nicht immer sinnvolle oder nachvollziehbare, geschweige denn korrekte) Entscheidungen. Ein Bekannter hat mir auch einst gesagt, dass man bei einem großen Autohersteller in Norddeutschland den Umstieg auf C# ablehnte und bei VB blieb, da die Abteilung, welche für die Evaluierung zuständig ist eben nur VB ausreichend beherrscht (wobei das ausreichend sich eben auf die Sicherstellung der Korrektheit des Codes bezieht!). Natürlich muss man hier zwischen Sinn und Unsinn abwägen, immerhin gilt VB nicht unbedingt als beliebteste Sprache. Trotzdem gibt es halt auch andere Aspekte als die persönliche Vorliebe und den gefühlten Komfort.
Nur um es klar zu stellen, ich bin natürlich ein großer Java - Fan. Arbeite schon lange mit der Sprache und finde die Konzepte alles andere als schlecht. Natürlich habe ich schon schlechte Java - Anwendungen gesehen, aber eben auch verdammt gute. Die Qualität und der "Fremndkörperfaktor" hängen häufig mehr vom Entwickler ab, als von allem anderen. Wie gut einem eine Anwendung gefällt oder nicht ist und bleibt doch sicher eher persönlicher Geschmack. Viele meiner Kollegen empfinden z.B. die Ribbons des aktuellen MS Office als absoluten Fremdkörper! Mir geht es so mit dem seit Windows XP verfügbaren neuen Startmenü, alles reine Geschmackssache.
Wenn jmd. keinen Sinn in Java sieht, dann steht es ihm doch frei die Sprache zu meiden. Ein wirklich überzeugendes Argument, dass die Nutzung schlecht wäre habe ich noch nicht gelesen. Schlechte Anwendungen hab ich noch mit jeder Sprache hinbekommen
Gegen persönliche Vorlieben kann man nichts tun, da sollte man jetzt aber auch nicht den 10.000.000.000.000 Glaubenskrieg zwischen Java und dem Rest der Welt heraufbeschwören. Immerhin ist das Fazit eh klar, nach endlosem auf der Stelle treten kommt der diplomatische Schlusssatz, dass alle Sprachen für bestimmte Voraussetzungen super sind (z.B. für die, dass man nur diese eine Sprache beherrscht).
Besten Gruß,
Der Unwissende