Zitat von
Bernhard Geyer:
Zitat von
Phoenix:
Dann: Java taugt an der Oberfläche überhaupt nicht. Es gibt - und das geben sogar gestandene Java-Entwickler zu - kein gescheites
GUI-Framework, was auch nur Ansatzweise taugt.
Dem möchte ich wiedersprechen. Es gibt Frameworks mit denen man
GUI erstellen kann denen du kein bischen anmerkst das Java dahinter steckt.
Und wie aufwändig ist es, diese anzuprogrammieren?
Zeig mir bitte mal ein Java-
Gui Framework mit passendem Designer, das so einfach zu handhaben ist wie die
VCL (oder von mir aus auch MFC) und entsprechende optische Ergebnisse (z.B. auch mit Ribbons) erzielt. Ich bin mir sicher Du wirst keines finden.
Zitat von
Bernhard Geyer:
Zitat von
Phoenix:
Also im Prinzip heisst das: Wenn es keinen absolut zwingenden Grund gibt, die Plattform zu wechseln: Bei Delphi bleiben. Ansonsten würde ich sowieso von Java abraten, und lieber auf .NET / Mono setzen.
Ob nun Java/.NET oder Native
Win32 Delphi besser ist hängt von den Rahmenbedingungen ab. Es gibt noch einge Bereiche in denen .NET nichts gleichwertiges entgegensetzen kann. Oder gibt es sowas umfassendes wie Apache mit all seinen Unterprojekten?
Wegen der Rahmenbedingungen habe ich ja gesagt, sofern es keinen zwingenden Grund gibt die Plattform zu wechseln (also weg von Native code), sollte man lieber bei Delphi bleiben. Ich denke, wenn es um Desktop-Applikationen für Windows geht, ist man hier super aufgehoben.
Wegen der Tauglichkeit von .NET: Mal davon abgesehen, dass sogar die Apache-Projekte von Microsoft teilweise mitfinanziert werden: CodePlex ist eine gute Anlaufstelle. Es dürfte inzwischen nur eine Handvoll Apache-Projekte geben, für die es kein .NET Gegenstück (sei es von MS direkt oder auf CodePlex oder in freier Wildbahn) gibt. Und was war nochmal das Apache-Gegenstück zu Silverlight? Oder zu WPF?
Zitat von
Bernhard Geyer:
Zum Fragesteller zurück: Eine reine Code-Umsetzung bringt nix wenn damit viele gewachsene Unzulänglichkeiten einer
VCL-Implementierung übernommen werden.
Ob Unzulänglich oder nicht sei mal dahingestellt. Auf jeden Fall taugt
RTL /
VCL-Code auf Managed-Seite (Sei es jetzt Java oder .NET) nichts. Da fehlen einfach alle wichtigen Klassen für Delphianer
Im Prinzip endet ein Plattformwechsel von native zu managed oder umgekehrt am sinnvollsten in einem Re-Write from Scratch. Managed untereinander ist noch relativ ordentlich austauschbar (Beispiel Blackfish). Aber um den Aufwand zu rechtfertigen muss da schon ein Grund hinterstehen, der das wirklich zwingend notwendig macht.
Wenn es 'nur' um die Zukunftssicherheit der Applikation geht, dann kann man z.B. mit Hydra den alten Code noch eine Weile lang in die .NET Welt mitnehmen. Aber da ist Java dann auch wieder aussen vor. Und den Stress mit Java (compile once, debug everywhere and on every runtime) will sich ein Delphianer und .NET'ler eigentlich nicht geben. Dafür werden wir in aller Regel nicht gut genug bezahlt.
