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 ;-)

[DelphiDeveloper]

danke für die Info,
dann schaue ich mir das MONO nochmal in einer neueren Version an!

Jetzt sind wir eigentlich schon out of topic. Die Infos sind natürlich sehr nützlich für mich.
Danke nochmal an die Beteiligten.

Aber nochmal zu meinen Eingangsfragen?

-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? Auf der Hibernate Seite steht es nämlich nicht
als supportete Datenbank sondern lediglich der Hinweis:

"Hibernate has also been tested with and is believed to be compatible with current versions of:
...
Firebird (1.5 with JayBird 1.01 tested)"

[Phoenix]

Zitat:

Zitat von DelphiDeveloper

-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?

Wie schon gesagt: Java und GUI gehen nicht zusammen. Es gibt keine tauglichen "Gui-Builder" für Java. Erst recht keine guten. Java-Guis werden State-of-the-art von Hand im Code - also dynamisch - erzeugt. Das ist offenbar sowas wie eine Überzeugung von Java-Entwicklern. 'Komponenten' kannst Du daher im Java-Bereich auch vergessen: Die Java-Leute kennen kein RAD (und wollen es offensichtlich auch nicht kennenlernen).

Das ist übrigens vollkommen unabhängig davon, ob Du Swing oder SWT benutzt. Eine Oberfläche 'zusammenklicken' ist in der Java-Welt böse. Deswegen sagt ich ja: Veranschlage für eine Java-Gui in etwa drei mal so viel Zeit wie für eine vergleichbare Delphi-Oberfläche. Wenn Du wirklich Jahrelang erfahrene Java-Gui-Entwickler daran sitzen hast ist es immer noch doppelt so viel Zeit.

[Missionar]

Java Builder

[Bernhard Geyer]

Zitat:

Zitat von DelphiDeveloper

...
2) 30% sind PowerUser die 500-1000 von Datensätze pro Tag erfassen
...
Gerade wegen 2) müssen wir eine umfangreiche Desktop Lösung entwickeln. Wo durch SchedulerDienste auch Daten aus anderen Systemen importiert/exportiert werden.

Sollte auch über entsprechende reine Web/Browserlösungen gehen.

Zitat:

Zitat von DelphiDeveloper

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

Wenn du auf Serverseite Windows vorrausetzen kannst, so wäre auch dein bestehender Delphi-Code nach umbau auf extern verwendbare API auch bei einer Weblösung verwendbar. Stichwort wäre hier SOA.

[mquadrat]

Wenn du einen tollen GUI Builder findest, will ich den auch haben :-)

Bisher ausprobiert:

- Visual Editor Project von Eclipse. Inkompatibel mit der aktuellen Eclipse Version. Und wenn man ihn doch zum Laufen kriegt, neigt er dazu nicht richtig zu funktionieren. Das kann vom Nicht-Anzeigen von Propertys bis zum Nicht-Mehr-Rendern-Können von Forms gehen.
- Window Builder. Der kam bei mir irgendwie auch nicht richtig ans Laufen. Hab mich damit allerdings auch nicht so wahnsinnig intensiv beschäftigt.
- Jigloo. Bei dem bin ich momentan. Funktioniert eigentlich ziemlich zuverlässig. Mitunter aber etwas langsam beim Parsen der GUI Klasse.

Was noch auf dem Zettel steht:

- JBuilder. Allerdings kann das Ding wieder nur SWING :(

[DelphiDeveloper]

@mquadrat

Danke für die Info! Ich werde mir wohl auch jigloo als erstes ansehen.

Wie ist es da mit den Controls? Wird man damit glücklich?

Gibt es dazu auch noch Komponentenhersteller wie bei Delphi,
wo ich wir sowas wie ein Quantumgrid kaufen könnte?

mfg
delphideveloper

[Angel4585]

Schonmal mit NetBeans gearbeitet? Da ist ein GUI-Builder integriert und der Umstieg von Delphi zu NetBeans war(zumindest für mich) sehr einfach.