Delphi to Java

[r_kerber]

Zitat von mkinzler:

Nein, SWT wird nativ auf den einzelnen Plattformen implementiert (wie auch WinForms bei .Net). Deshalb sind SWT Oberflächen keine Fremdkörper, da es auf Windows ja Standard Windowscontrols sind. SWT muss aber für jede Platform vorliegen, was bei APT/Swing natürlich nicht der Fall ist, da diese ja in Java implemnetiert sind.

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.

[mkinzler]

IBM bietet diese aber für die wichtigsten Platformen an ( MS ja auch, allerdings aus ihrer Sicht)

[Der_Unwissende]

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

[mschaefer]

Ja interessantes Statement. Es gibt wieder einge Hinweise auf die Bibliotheken und ich lese so heraus, dass wenn man die Plattformunabhängigkeit etwas zurückstellt sich unter Windows mit Java zu NET vergleichbare Anwendungen erstellen lassen.

Würde die Betonung von Glaubenskrieg etwas wegnehmenmm, denn letzlich ist der Ausgangspunkt der Diskussion ja gewesen wo man hingeht, wenn native Delphi Anwendungen dem Kunden nicht mehr zu verkaufen sind.

Was für eine Zusammenstellung von Bibliotheken würde man den bei Java verwenden oder wo sollte man sich einarbeiten, wenn man bisher mit Delphi native gearbeitet habe und jetzt in einer Umgebung mit Einzel- und Webanwendungen weiterarbeitet?

Grüße // Martin

[Der_Unwissende]

Zitat von mschaefer:

Ja interessantes Statement. Es gibt wieder einge Hinweise auf die Bibliotheken und ich lese so heraus, dass wenn man die Plattformunabhängigkeit etwas zurückstellt sich unter Windows mit Java zu NET vergleichbare Anwendungen erstellen lassen.

Etwas zurückstellt muss hier wirklich relativiert werden. Soweit man Linux, MacOS und Windows (inkl. der Serverversionen!) als Basis nimmt, so findet man hier auf jeden Fall Ansätze, welche sich gleichermassen auf allen diesen Plattformen verwenden lassen. Das die Liste der unterstützten System nicht auf diese beschränkt ist sollte sich von selbst verstehen, ob es nun aber eine Qt Implementierung für AIX gibt kann ich nicht sagen. Im "Notfall" gibt es häufig auch noch fallback Lösungen die direkt in Java geschrieben sind. Als Beispiel sei hier JAI (Java Advanced Imaging) genannt, da gibt es für Windows und Linux eine dyn. Bibliothek, für alle anderen Systeme eine reine Java Lib.

Ob eine Plattform außen vor bleibt hängt vor allem davon ab, wie wichtig das Anwendungsgebiet auf der Plattform ist. Muss man zum Beispiel auf OpenGL unter HP-UX verzichten (fiktives Beispiel!), dann kann man das vielleicht gut verschmerzen.

Zitat von mschaefer:

Würde die Betonung von Glaubenskrieg etwas wegnehmenmm, denn letzlich ist der Ausgangspunkt der Diskussion ja gewesen wo man hingeht, wenn native Delphi Anwendungen dem Kunden nicht mehr zu verkaufen sind.

Da habe ich wohl den Ausgangspunkt nicht richtig wahrgenommen. Für mich las sich der Thread ein wenig wie die (ewige) Diskussion um die wahre Sprache(n). Werde aber diese Anregung aufnehmen und es aus dem Blickwinkel des Wechselns betrachten.

Zitat von mschaefer:

Was für eine Zusammenstellung von Bibliotheken würde man den bei Java verwenden oder wo sollte man sich einarbeiten, wenn man bisher mit Delphi native gearbeitet habe und jetzt in einer Umgebung mit Einzel- und Webanwendungen weiterarbeitet?

Hm, die Frage ist so allgemein gestellt, dass mir eine Antwort unmöglich scheint. Ich meine ein Teil ist klar, Du solltest Dich definitiv einarbeiten wenn Du wechseln wollen würdest. Ob Dir jetzt Leute wie ich predigen das Java einfach funktioniert und alles schöner, besser und einfacher macht oder eben jmd. anderes das Gegenteil behauptet, letztlich musst Du mit der Sprache zurecht kommen, sonst wird das nichts.

Was Du nun aber für Bibliotheken verwenden solltest hängt doch sehr, sehr stark von der Art der Einzel- und Webanwendungen ab. Auch bei Delphi hast Du sicherlich über die Zeit für unterschiedliche Aufgaben sehr unterschiedliche Bibliotheken kennengelernt und verwendet. Und so wie Delphi eine ganze VCL besitzt gibt es auch bei Java schon eine Menge von packages mit einer Menge von Klassen, welche die Standardbibliothek darstellen. An zusätzlichen Bibliotheken dürfte Java hingegen deutlich mehr bieten (soweit das noch aktuell ist werden z.B. ateilig die meisten Sourceforge - Projekte in Java geschrieben). Die Menge sagt aber nichts über die Qualität aus, ist klar!
Bei Webanwendungen solltest Du Dich mit Servlets und Java Server Pages (JSPs) vertraut machen. Diese setzen einen speziellen (kompatiblen) Webserver vorraus, übliche Basis für einfache Anwendungen ist sicherlich der Apache Tomcat.
Gerade für die Entwicklung von Webanwendungen findest Du gleich eine Unzählige Anzahl von bekannten und weit verbreiteten Frameworks, allen voran Java EE, aber auch gute Alternativen wie Spring, Struts, JavaServer Pages, der Relationale Objektmapper Hibernate und und sind interesant. Je nach Anforderung kommen aber viele weitere Möglichkeiten hinzu. Als Beispiel seien hier Portal Server genannt, welche Portlets nach dem JSR 168 Entwurf verwalten, entsprechend kann dieser Standard berücksichtigt werdne. Das sieht natürlich für Sprachen wie .net nur geringfügig anders aus. So wird z.B. Spring und Hibernate auch für die .net Welt angeboten (was auf die große Verbreitung und Beliebtheit dieser Frameworks zurückzuführen sein dürfte).