Delphi Anwendung mit Java neu entwickeln

[DelphiDeveloper]

Wir wollen ein größere Delphi5/DevExpress/IbOjects/Quickreport/Firebird 1.5 Anwendung (Entwicklunsgzeit ca 1500 Personentage),
die bei ca. 1000 Kunden im Einsatz ist, unter Java neu entwickeln.

Als Technologien/Tools sollen hierbei verwendet werden:

Eclipse
GUI SWT
Firebird 2.1
JDBC oder Jaybird
Hibernate als O/R Mapper
Jasperreports und Designer iReports

Als Delphientwickler und Java Neuling sehe ich bei unserem Vorhaben einige
technische Risiken und wollte mir über diesem Beitrag eure Meinungen dazu einholen.

-Reichen die SWT Möglichkeiten aus ein komfortables GUI zu bauen. Ich denke da etwa an das Quantumgrid,
gibt es in SWT oder eventuell als ThirdParty in der JAVA Welt so etwas?
-Gibt es evtl. einen guten GUI Builder den man sich kaufen sollte?
-Kann ich mit Hibernate alle Firebird Features nutzen?



mfg
Delphideveloper

[Phoenix]

Hi,

ich würde diese Entscheidung nochmal überdenken.
Nicht, weil ich persönlich Java nicht mag, sondern weil Java auf dem Desktop einfach nicht passt.

Sogar langjährige Java-Entwickler, für die es nichts anderes mehr gibt, fangen an öffentlich rumzumeckern wenn es an die Gui geht. Alles in allem bedeutet das nämlich: Nie mehr Rad. Es gibt keine tauglichen Rad-Tools für Java, und die User-interfaces die bei Java derzeit rauskommen sind nicht nur Potthäßlich, sondern bedienen sich in etwa genauso Elegeant, als würdest Du eine tragende Kuh fliegen.

Der Aufwand, eine Gui in Java so bedienbar (und ich rede hier erstmal nur von Usability, nicht von Ästhetik) zu machen, wie man sie sich in Delphi zusammenklickt ist erfahrungsgemäß um Faktor 3 höher.

Wenn man aber mal den normalen Entwicklungsprozess einer guten Desktop-Anwendung ansieht, wie viel Zeit man selbst mit Delphi in eine gute Gui steckt, dann wird man schnell sehen, dass normalerweise um die 60% - 80% an der Oberfläche verbraten werden.

Gehen wir bei Euch beispielsweise also mal nur von 40% aus, dann habt ihr in Eurem Projekt ca. 600 Tage an der Gui verbacht. Das heisst, bei ungeheuer optimistisch geschätzen doppelten Aufwand (dann arbeiten aber nur Leute da dran, die Jahrelang nichts anderes als Java-Guis gemacht haben), werdet ihr bei einer Neuentwicklung allein 1200 Tage nur in die Gui stecken, um das nachzubauen was ihr jetzt schon habt. Die restlichen 900 Tage für die Logik sind da noch nicht drin.

Und nach diesen 2100 Manntagen ist die Anwendung erstmal nur portiert, und noch nicht weiterentwickelt.

Tut Euch einen Gefallen und sucht mal gezielt im Internet nach Java-Entwicklern, die über die ganzen verfügbaren Gui-Frameworks gleichermassen abkotzen. Ihr tut Euch damit echt keinen Gefallen. Java mag auf dem Server seine Stärken ausspielen, aber definitiv nicht auf dem Desktop. Da gehört das einfach nicht hin, und das sagen auch die langjährigen Java-Entwickler.

[Bernhard Geyer]

Ein paar Fragen:

- Wieso soll die Anwendung portiert werden? Nur damit man Plattformunabhänig ist obwohl 99% der Kunden Windows im Einsatz haben.
- Und wenn neu entwickelt wieso dann noch scheinbar als Desktop-Anwendung? Wenn schon dann ein richtiger neuer Ansatz mit Java Application Server und Browser auf dem Client mit AJAX geschmückt.

[Phoenix]

Zitat:

Zitat von Bernhard Geyer

Wenn schon dann ein richtiger neuer Ansatz mit Java Application Server und Browser auf dem Client mit AJAX geschmückt.

Das ist sicher weniger Aufwand als eine Gui mit Java zu bauen. Aber dank verschiedener Browser und den einen oder anderen.. sagen wir Unzulänglichkeit in den unterschiedlichen Ajax-Bibliotheken sitzt man hier aber auch wieder um einiges Länger an der Oberfläche als mit Delphi.

[Bernhard Geyer]

Die wichtigest Frage ist ja nach dem: WARUM

Denn so mal schnell 1000 Tage (Architektur und "sonstiger" kleinkram) * 50-100 € Entwicklerstundenkosten (gemeinkosten etc. mit eingerechnet = 500.000€ - 1 Mio. € Auzugeben um nur Java zu haben. Das kann sich Siemens oder ähnliches leisten (haben es ja teilweise sowas vor 10 Jahren gemacht und hatten dann unbedienbare SW).

[DelphiDeveloper]

@Bernhard kurz nach dem warum?

Ja du hast Recht Plattformunhabhängigkeit ist nicht vorgesehen, da 99% Windows Anwender sind!

Unsere Kunden kann man grob in 3 Klassen einteilen.

1) 40% haben keinen Onlinezugang.
2) 30% sind PowerUser die 500-1000 von Datensätze pro Tag erfassen
3) 30% sind potentielle Kunden wo eine Weblösung sinnvoll wäre.

Gerade wegen 2) müssen wir eine umfangreiche Desktop Lösung entwickeln. Wo durch SchedulerDienste auch Daten aus anderen Systemen importiert/exportiert werden.

3) Ist noch zukunftsmusik wo mal hin will.

Die Vision ist, durch die Neuentwicklung in Java die Businessschicht auch für die Webclients nutzen zu können.

mfg
DelphiDeveloper

[BUG]

Evtl. wäre es vielleicht ja auch möglich "in Java die Businessschicht" zu programmieren und den Rest bzw. die GUI weiterhin in Delphi zu entwickeln?

MfG,
Bug

[Phoenix]

Zitat:

Zitat von DelphiDeveloper

Die Vision ist, durch die Neuentwicklung in Java die Businessschicht auch für die Webclients nutzen zu können.

Hrm. Schonmal daran gedacht, 'einfach nur' die Businesschicht in Delphi zu belassen und auf dbExpress umzustellen? Das hat den Vorteil, dass man die Businessschicht dann in Delphi belassen und in ein .NET Assembly packen kann. Diese bestehende Logik kann man dann ohne großen Aufwand via Webservices / ASP.NET Webclients (die dann aber bitte in C# oder Oxygene, Delphi.NET will man sich ausser legacy-Code -> Assembly nicht antun) effizient erweitern kann.

Der riesen Vorteil ist a) ihr könnt bestehenden Code (Euer bisheriges Kapital) weiterverwenden und b) die Umstellung von Delphi zu .NET ist bei weitem nicht so gravierend wie der von Delphi zu Java. Anders Hejlsberg hat schliesslich nicht an Java mitgearbeitet :)

[DelphiDeveloper]

Bisher ist die Anwendung keine 3 Schicht Architektur,
sondern die DB Zugriffe finden über einige Datamodule statt.

DBExpress anstelle von IBObjects, würde ich ja noch in Kauf nehmen,
aber ASP.NET scheidet wohl aus, weil im Serverbereich bei uns Windows tabu ist,
und das MONO Framework scheint auch nicht 100% kompatibel zu sein.

[Phoenix]

Zitat:

Zitat von DelphiDeveloper

und das MONO Framework scheint auch nicht 100% kompatibel zu sein.

Das halte ich für ein gaaaanz übles Gerücht. Ich habe bisher noch keine ASP.NET Webanwendung hinbekommen, die nicht unter Mono/Apache laufen würde. Und ASP.NET ist mein Hauptgeschäft ;-)