Delphi vs. Java

[tommie-lie]

Zitat:

Zitat von MacNuke

Ich glaube kaum das MS.NET jemals komplett plattformunabhängig wird. Microsoft wird immer etwas einbauen, damit es nur unter Windows läuft und auch wirklich nützlich ist.

Wie soll das gehen? Die Grundfeatures sind jetzt schon plattformunabhängig, wan WinForms wird bereits gearbeitet. Microsoft wird immer sein Framework an die Windows-Features anpassen, aber das Framework ist "nur" ein Framework. Wie etwas implementiert wird, ist nirgends definiert, es wird nur gesagt, daß diese und jene Klasse diese und jene Features haben soll. Wie das getan wird, ist dabei irrelevant. Das kommende Avalon-Framework kann ebenfalls ohne Weiteres auf andere Plattformen portiert werden, selbst wenn Avalon nicht verfügbar ist, die Implementierung muss lediglich die gleichen Feautres bieten können.

Zitat:

Zitat von MacNuke

Wenn du was .NET mäßiges haben möchtest und was WIRKLICH plattformunabhängig ist, dann nimm Mono.

:lol: You made my day!

Zitat:

Zitat von MacNuke

Leider gibt es, soweit ich weiß, noch keine Bindings für FreePascal. Borland bleibt ja anscheinend bei MS.NET.

Noch sowas und ich ersticke... http://www.delphi-forum.de/images/sm...on_roflmao.gif

[MacNuke]

Zitat:

Zitat von tommie-lie

Wie soll das gehen? Die Grundfeatures sind jetzt schon plattformunabhängig, wan WinForms wird bereits gearbeitet.

Eine Grundvorraussetzung für plattforumunabhängiges entwickeln ist nunmal, das die Bibliotheken für alle Systeme verfügbar sind. Bei .NET ist das nicht der Fall. Klar machen die Jungs und Mädels von Mono es halt nach, aber sie hängen dem Original immer hinterher. Und von MS erhalten sie nicht viel Hilfe dafür.

Alles was unter Mono läuft, läuft auch unter .NET. Aber alles was unter .NET läuft, läuft zwangsläufig nicht unter Mono. Und es würde mich wundern wenn bald .NET Frameworks für Linux, OS X, Solaris, QNX, ... von Mirosoft auftauchen würden.

Oder würdest du die WinAPI plattformunabhängig nennen, nur weil es WINE gibt? Oder gar DirectX, weil es Cedega gibt?

[Phoenix]

Zitat:

Zitat von MacNuke

Eine Grundvorraussetzung für plattforumunabhängiges entwickeln ist nunmal, das die Bibliotheken für alle Systeme verfügbar sind. Bei .NET ist das nicht der Fall. Klar machen die Jungs und Mädels von Mono es halt nach, aber sie hängen dem Original immer hinterher. Und von MS erhalten sie nicht viel Hilfe dafür.

Ist doch klar. Microsoft unterstützt ja auch nicht dieses strunzdoofe Mono, sondern das dotGNU Projekt. :roll:

Zitat:

Zitat von MacNuke

Alles was unter Mono läuft, läuft auch unter .NET. Aber alles was unter .NET läuft, läuft zwangsläufig nicht unter Mono. Und es würde mich wundern wenn bald .NET Frameworks für Linux, OS X, Solaris, QNX, ... von Mirosoft auftauchen würden.

Wird auch nicht bald auftauchen. Ist nömlich schon lange aufgetaucht: dotGNU. Läuft zumindest schonmal mal unter MacOS X und Linux, rest kommt noch. Volle Unterstützung für .NET 1.1 wird gegen Mitte / Ende des Jahres erwartet.

[Robert_G]

Zitat:

Zitat von Phoenix

Wird auch nicht bald auftauchen. Ist nömlich schon lange aufgetaucht: dotGNU. Läuft zumindest schonmal mal unter MacOS X und Linux, rest kommt noch. Volle Unterstützung für .NET 1.1 wird gegen Mitte / Ende des Jahres erwartet.

Inclusive CAS und einem ebenbürtigen JIT?

[tommie-lie]

Zitat:

Zitat von MacNuke

Zitat:

Zitat von tommie-lie

Ich glaube kaum das MS.NET jemals komplett plattformunabhängig wird.

Das habe ich nie behauptet :mrgreen:

Zitat:

Eine Grundvorraussetzung für plattforumunabhängiges entwickeln ist nunmal, das die Bibliotheken für alle Systeme verfügbar sind.

...von welchem Hersteller ist mir da reichlich egal.

Zitat:

Und von MS erhalten sie nicht viel Hilfe dafür.

Stimmt, warum sollte Microsoft sich auch dazu hinablassen? Sie würde kein Geld dafür kriegen und auch sonst nicht dran profitieren.

Zitat:

Alles was unter Mono läuft, läuft auch unter .NET.

Falsch.

Zitat:

Aber alles was unter .NET läuft, läuft zwangsläufig nicht unter Mono.

Ebenfalls falsch.

ASP.NET ist AFAIK ziemlich komplett portiert. WinForms laufen noch nicht vollständig oder zuverlässig unter Mono. Der Pseudostandard für GUI ist GTK#, bevor daß unter .NET läuft muss erst GTK# (als Assembly) und das Toolkit installiert werden.

Zitat:

Und es würde mich wundern wenn bald .NET Frameworks für Linux, OS X, Solaris, QNX, ... von Mirosoft auftauchen würden.

Dafür tauchen aber Frameworks für Linux, MacOSX und Windows von der Mono-Cummunity, unterstützt von Novell.

Zitat:

Oder würdest du die WinAPI plattformunabhängig nennen, nur weil es WINE gibt? Oder gar DirectX, weil es Cedega gibt?

Unter dem pragmatischen Gesichtspunkt, daß ich Win32-Programme unter mehreren Plattformen ausführen möchte, ja.

@Phoenix: Meinst du nicht eher Rotor? :gruebel:

[MacNuke]

Zitat:

Zitat von tommie-lie

Ebenfalls falsch.

Hö?

Was ist daran falsch? Demnach müsste jedes .NET-Projekt also unter Mono laufen. Tut es aber nicht.

Das du behauptest hast, .NET wäre Plattforumunabhängig habe ich auch nicht behauptet. ;) (finde ich doof, das hier Zitate nicht aus den Zitaten entfernt werden)

Ich bezog mich dabei nur auf:

---
Will man in naher Zukunft Plattformunabhängig -> .NET
---

Mir ist klar, das Mono mehr oder weniger ein .NET für alle anderen Systeme ist (dotGNU hängt noch ne Ecke hinterher). Das habe ich ja selbst behauptet. ;) Jedoch hängt es halt immer hinterher. Microsoft wird sich sicher nicht aufhalten lassen in .NET Funktionen einzubauen, die Longhorn-Features benötigen (z.B. die grafische Oberflähche, Dateisystem). Klar ist die Spezifikation dahinter offen, nur wird sich das schlecht in Mono umsetzen lassen. Und dann müsste Borland ja auch noch den Compiler portieren, damit ihr es aus Delphi ansprechen könnt. FreePascal ist erst bei Delphi7.

Das Konzept mag plattformunabhängig sein, jedoch die Umsetzung dahinter nicht.

Und genau das meinte ich auch mit WINE. Wine bildet die WinAPI nach. Jedoch nicht unbedingt vollständig und originalgetreu. Daher ist auch die WinAPI nicht Plattformunabhängig, nur weil es Projekte gibt, die es nachbilden.

[tommie-lie]

Zitat:

Zitat von MacNuke

Zitat:

Zitat von tommie-lie

Ebenfalls falsch.

Was ist daran falsch? Demnach müsste jedes .NET-Projekt also unter Mono laufen. Tut es aber nicht.

Nicht jedes. Meine Aussagen, daß deine Aussagen falsch waren, habe ich im Absatz darunter begründet und näher ausgeführt. Es ist nunmal falsch, daß eine .NET-Anwendung nicht unter Mono läuft, es kommt drauf an, welche .NET-Anwendung man nimmt.

Zitat:

Jedoch hängt es halt immer hinterher.

Was verständlich und normal ist. Dennoch ermöglicht es, .NET-Anwendungen unter Linux zu verwenden.

Zitat:

Microsoft wird sich sicher nicht aufhalten lassen in .NET Funktionen einzubauen, die Longhorn-Features benötigen (z.B. die grafische Oberflähche, Dateisystem). Klar ist die Spezifikation dahinter offen, nur wird sich das schlecht in Mono umsetzen lassen.

Wieso nicht? Objekte zu implementieren, die das gewünschte fordern, ist technisch kein Problem. Wenn die Feautures von Avalon nicht vollständig in GTK enthalten sind, hat man in der Tat ein Problem, das sich entweder durch weglassen dieser Features (die wahrscheinlich eh spezieller Natur sein werden) oder durch Erweitern von GTK lösen lässt (oder nicht zuletzt durch Verwendung eines anderen toolkits, das vielleicht näher an Avalon rankommt).

Zitat:

Und dann müsste Borland ja auch noch den Compiler portieren, damit ihr es aus Delphi ansprechen könnt. FreePascal ist erst bei Delphi7.

Was faselst du immer von Delphi und FreePascal? .NET-Assemblies von Delphi werden, sofern so entwickelt, daß sie die portierten Assemblies benutzen, auch unter Mono laufen. Und FreePascal ist ein nativer Pascal-Compiler, .NET ist nicht deren Ziel.

Zitat:

Und genau das meinte ich auch mit WINE. Wine bildet die WinAPI nach. Jedoch nicht unbedingt vollständig und originalgetreu. Daher ist auch die WinAPI nicht Plattformunabhängig, nur weil es Projekte gibt, die es nachbilden.

Es ermöglicht (in beschränktem Umfang) das Entwickeln von Software für mehrere Plattformen. Die Win32-API ist nur eine API, die an sich kann ich auch unter DOS zur Verfügung stellen, wenn ich Lust habe. Win32 als Funktionsbibliothek ist zwar nicht von Microsoft, dafür aber von Wine nach Linux portiert worden, Win32-Programme laufen unter Linux, wenn auch nicht alle. Aber Wine ist mittlerweile ziemlich weit, zumindest was den API-Stand von Win98 angeht.
Pragmatisch argumentiert ist Win32 auf Linux verfügbar, nicht vollständig, aber größtenteils.

[MacNuke]

Hey, freundlich bleiben. "was faselst du" ist nicht unbedingt mein Niveau einer Diskussion.

Ich schätze mal wir haben unterschiedliche Auffassungen von Plattformunabhängig.

Ich meine damit, das man bedenkenlos programmieren kann, mit allen Features die es gibt und es überall läuft.

Du meinst wohl eher, es ist plattformunabhängig wenn ein Grundlevel überall läuft. Zumindest lese ich das so aus deinem Text heraus. Das ist aber nicht meine Auffassung, die ich hier vertrete. Wenn dann alles.

Und das bietet .NET nicht und wird es wahrscheinlich auch nie tun, sofern MS das Konzept nicht mal irgendwann fallen lässt und nicht mehr weiter entwickelt.

[Speedmaster]

Was faselst du da?? :mrgreen:
.net ist Plattformunabhängig auf einem gewissen Grundlevel, aber es gibt inzwischen z.b. schon Packages die es erlauben WinForms auf MacOS z.b. zum laufen zu bekommen!

[tommie-lie]

Zitat:

Zitat von MacNuke

Hey, freundlich bleiben. "was faselst du" ist nicht unbedingt mein Niveau einer Diskussion.

Wäre ich unfreundlich, hätte ich gesagt "Was redest du da für einen Sch***?":mrgreen:

Zitat:

Ich schätze mal wir haben unterschiedliche Auffassungen von Plattformunabhängig.

Ich meine damit, das man bedenkenlos programmieren kann, mit allen Features die es gibt und es überall läuft.

Ja, haben wir, was ich unter Plattformunabhängigkeit verstehe habe ich oben schon angedeutet. Nochmal konkret: Ich programmiere einen Quellcode und der läuft, mit welchen Mitteln auch immer, unter mehreren Plattformen. Ob ich da nun eine Bilbiothek von einem Hersteller für mehrere Plattformen habe, oder hunderte von Bilbiotheken mit identischer API für verschiedene Plattformen, ist mir da egal. Und Plattformunabhänigkeit mit höchstmöglicher Performance hat für mich immer auch etwas mit dem Programmierer zu tun.

Zitat:

Du meinst wohl eher, es ist plattformunabhängig wenn ein Grundlevel überall läuft. Zumindest lese ich das so aus deinem Text heraus. Das ist aber nicht meine Auffassung, die ich hier vertrete. Wenn dann alles.

Ja, das wäre das Optimum. Mit GTK# gibt es die Möglichkeit, GUIs für Linux und Windows zu schreiben, WinForms sind einfach noch nicht so weit. Wenn ich plattformunabhängig programmieren will, suche ich mir vorher meine Bibliotheken zusammen, mit denen ich das tun kann. Will ich dafür .NET nutzen, gibt es nicht für jedes Problem eine fertige Bibliothek. Da habe ich zwei Möglichkeiten: 1) ich portier' mir meine Bilbiothek selbst, oder 2) ich verzichte auf ein spezielles Feature. Habe ich genügend Zeit, entscheide ich mich für 1), habe ich sie nicht, nehme ich die zweite Möglichkeit oder zur Not die dritte: Ich schränke die Plattformunabhängigkeit ein. Für gewöhnlich ist man aber als Programmierer pragmatisch und nimmt das, was man kriegen kann, in diesem Fall .NET mit GTK# und keine weiteren plattformabhngigen Assemblies.
Wenn du write once, run everywhere mit sämtlichen Features jeder Zielplattform haben willst, gibt es keine Möglichkeit, weder mit .NET noch mit Java. Wenn d dich auf write once, compiler anywhere beschränkst, kannst du dir wenigstens noch mit der MAchete einen Weg durch den IFDEF-Dschungel schlagen...

[MrSpock]

Kommt bitte zum Thema zurück.

Wenn MacNuke klar sagt, dass er den Ton für unangebracht hält, ist es umso unhöflicher, dieselbe Aussage noch einmal zu wiederholen. Die Aussage durch eine ähnlich persönlich verletzende ist dann auch nicht besser. Diskutiert bitte sachlich und zum Thema, sonst mache ich hier zu.

[FBrust]

Hallo,

danke für Eure Antworten.

Der Hintergrund ist, dass wir eine Anwendung haben (Datenbank, soll später C/S werden), die mit Delphi erstellt wurde (von uns selbst, nicht eingekauft). Diese Software wird auch bei Kunden installiert.

Nun kam einer daher und fragte, was wir denn machen würden, wenn morgen ein Kunde mit Linux käme. Wenn man plattformunabhängig sein wolle, müsse man das ganze in Java neu schreiben (stimme ich auch zu), ausserdem wären Java-Programme schneller als Delphi-Programme. :?:

Ich möchte das mal auf Windows beschränken, da man (wie weiter oben gesagt) ein Delphi-Programm nicht mit einem Java-Linux-Programm vergleichen kann (finde ich jedenfalls auch).

Die Anwendung ist eine Einzelplatzanwendung, die als Datenbank den ADS hat, später soll sie (auch via ADS) als Client/Server-Anwendung laufen. Es gibt Tabellen, in die im Laufe eines Jahres ca. 50.000 Datensätze eingetragen werden, die auch verarbeitet werden (Abfragen, Berechnungen etc.).

So, dies nur als ungefähre Angaben. Was meint ihr?


Gruß

Frank

Ach so: "Plattformunabhängig" hat für mich auch den Beigeschmack vom "kleinsten gemeinsamen Nenner".

[MacNuke]

Zitat:

Zitat von tommie-lie

Wenn du write once, run everywhere mit sämtlichen Features jeder Zielplattform haben willst, gibt es keine Möglichkeit,

Nein. Sämtliche Features des Frameworks und nicht der Zielplattform.

Das geht zur Zeit am besten mit Qt und GTK+. Java halt nur da wo es die RunTime gibt.

[Phoenix]

Zitat:

Zitat von FBrust

Wenn man plattformunabhängig sein wolle, müsse man das ganze in Java neu schreiben (stimme ich auch zu), ausserdem wären Java-Programme schneller als Delphi-Programme. :?:

Erstes: Ja. Korrekt.
Zweites: Kommt drauf an. ;-)

In der Regel sind native Win32/Executables deutlich (will heissen um Faktoren) schneller als entsprechende Java-Applikationen. Ist aber auch kein Wunder.

Leider wird dieser Geschwindigkeitsvorteil wie ich auch schon schrieb in Delphi durch die exzessive Nutzung der VCL meistens wieder zunichte gemacht, da diese nicht nur die Programme aufbläht sondern auch Performance kostet.

Dennoch: Meistens sind native Kompilate immer noch schneller als entsprechendes Java-Gewurschtel.


Ps: (Ich weiss nur nicht mehr wer das eingeworfen hatte): Nein, ich meinte nicht Rotor, sondern tatsächlich dotGNU. Im übrigen meinte jemand, dotGNU würde Mono hinterherhinken. Derjenige hat überhaupt gar keine Ahnung vom Stand der beiden Projekte. Fakt ist, das das Mono-Team sich gerade überlegt aufgrund des inzwischen viel zu gross gewordenen Abstandes zum dotGNU Projekt seine Arbeit einfach einzustellen, weil sie diese Differenz (durch das fehlende Knowhow) einfach nie mehr einholen könnten.

[MacNuke]

Zitat:

Zitat von FBrust

Nun kam einer daher und fragte, was wir denn machen würden, wenn morgen ein Kunde mit Linux käme. Wenn man plattformunabhängig sein wolle, müsse man das ganze in Java neu schreiben (stimme ich auch zu), ausserdem wären Java-Programme schneller als Delphi-Programme. :?:

Je nachdem. Liegt an der Programmierweise und Anwendung, was schneller ist.

Rein in der Datenverarbeitung (Berechnungen, String-Operationen, Arrays, etc.) ist Java eigentlich sehr schnell, da die RunTime mittlerweile sehr auf die Prozessoren optimiert ist und bei Mathe spezielle Algos benutzt.

Wenn ich mir z.B. Dev-Cpp (ist ja mit Delphi geschrieben) angucke finde ich diese auch nicht unbedingt schneller als Eclipse oder NetBeans.

[tommie-lie]

@MacNuke: Aber es ist lediglich eine frage der Zeit, bis alle Namespaces unterstützt sind. Das Framework selbst ja noch nicht produktiv einsetzbar, weil zu große Teile der API noch nicht verfügbar sind, und die freien Frameworks sind auf dem besten Weg zur vollständigen Implementierung. Wenn du allerdings als Framework auch das bezeichnest, was Microsoft willkürlich ohne Firmen-Präfix einbindet, nämlich zum Beispiel Avalon (statt Microsoft.Avalon), so wird .NET nie ohne Verzögerung plattformunabhängig sein. Aber solche Namespaces muss ich ja nicht nutzen, ich habe ja mit GTK# eine Alternative zu Avalon.


@FBrust: Ihr habt eine bestehende Datenbankanwendung, die ihr in Delphi geschrieben habt, und überlegt, diese nach Java zu portieren, nur weil irgendwann mal ein Linux-Kunde kommen könnte? :shock:
Habt ihr zuviel Gewinn und wisst nicht, wohin mit eurem Geld?
Eine komplette Neuentwicklung einer kompletten Anwendung dauert gerne mal ein Jahr. Wenn ihr dann noch eure Programmierer auf Java umschulen wollt, entsprechend länger. Wenn ihr bisher noch keine Kunden mit Linux-Wünschen hattet und ihr so viele Windows-Kunden habt, daß selbst 100 Linux-Kunden nur einen Bruchteil des Umsatzes ausmachen würden, lohnt sich IMHO eine Portierung nicht. Die würde dann mehr kosten als ihr durch den neu erschlossenen Markt wieder reinholen würdet. Außerdem solltet ihr erstmal schauen, wie groß der Linux-Markt für euch überhaupt ist. Was bringt eine komplette Neuentwicklung eines vorhandenen und funktionierenden Produktes, wenn es nachher eh nur 10 Leute gibt, die dieses neue Produkt überhaupt einsetzen würden, von denen 5 drauf angewiesen sind und von denen wiederum 4 beim Konkurrenzprodukt bleiben würden, das sie benutzen, weil ihr bisher keins angeboten habt.
Zur Geschwindigkeit würde ich sagen, daß es vermutlich kaum einen Unterschied machen wird. Ihr habt keine geschwindigkeitskritische Software und vermutlich ist bei großen Datenbanken die Datenbank selbst, bzw die Festplatte eher der Flaschenhals als der verwendete Datenbankclient. Es ist ja nicht so, daß ihr innerhalb von Millisekunden hunderte von Datensätzen auseinandernehmen und zusammensetzen müsstet.

[magicm247]

Zitat:

Nun kam einer daher und fragte, was wir denn machen würden, wenn morgen ein Kunde mit Linux käme. Wenn man plattformunabhängig sein wolle, müsse man das ganze in Java neu schreiben (stimme ich auch zu), ausserdem wären Java-Programme schneller als Delphi-Programme. Question

Als C/S ist hier Java für früher oder später eine interessante Lösung, könnten auch ApplicationServer zum einsatz kommen. Da kann Java sich richtig austun. Auch die Nutzung von JSPs sind bestimmt denkbar für die die realisierung einer WebLösung. Genügend Arbeitsspeicher vorrausgesetzt.

Die Clienten sind hier sicher egal, diese Würden als Delphi-Client bestimmt unter Wine einsetzbar sein , eine Linux-Version per Kylix würde auch schnell genug und den Migrationsaufwand in grenzen halten. Die Clients rein in Java zu lösen würde ich eher von absehen. Man könnte auch unter .net/mono die clients umsetzten und diese über webservices mit den java basierten servern werkeln lassen.

[fastplasma]

hey Leute,
arbeitet nur mit eclipse für java programmieren, der ist einfach der beste, soo viele möglichkeiten :dancer2:

[phXql]

Zitat:

Zitat von r_kerber

Zitat:

Zitat von Nicodius

lol mich schon sehr ... ich mag kurze programmteile schnell teste :roll:

Dann ist (das alte) VB am Besten für Dich geeignet! BTW: Auch Delphi braucht seine Zeit zum Erstellen eines Programmes.
Und nun ein Wort zur Lauzeitgeschwindigkeit. Im vergangenen Jahr gab's dazu eine Artikelserie in der c't von Arne Schäpers und Rudolf Huttary. Das überraschende Ergebnis: Am schnellsten arbeiteten Java- und C#-Programme. Mit Abstand folgten C++ (VS) und Delphi!

öhm, dieser C't-Test: Da gabs keinen eindeutigen gewinner, manchmal war Java vorne, manchmal c++, manchmal delphi...

[phXql]

Zitat:

Zitat von fastplasma

hey Leute,
arbeitet nur mit eclipse für java programmieren, der ist einfach der beste, soo viele möglichkeiten :dancer2:

und so schön schnell ^^

[FastJack2]

Hy all.. soa ich muss jetzt auch mal meinen Senf dazugeben, da ich einige Sachen, die hier erwähnt wurden einfach nicht für richtig halte....

Es scheint eine weit verbreitete Meinung zu sein, dass Java langsam arbeitet und ne schlechte Speicherverwaltung hat ....hier z.b. ein Zitat, um das zu verdeutlichen:

Zitat:

Zitat von magicm247

Ich habe noch keine Java-Anwendung gehabt, die vom Speicherverbrauch und der Geschwindigkeit akzeptabel war.

Diese Aussage ist schlichtweg FALSCH !

Sie stammt noch aus Zeiten, als Java wirklich noch langsam und ineffizient war, aber die Zeiten sind schon lange vorbei. Wenn ein Java Programm schlecht läuft liegt das viel eher an der Unfähigkeit der Programmierer.

Ein sehr schönes Beispiel, dass Java Apps auch sehr performant laufen können findet man hier: www.chromethegame.com Ich habe das Spiel selbst angespielt und mich hat es echt vom Stuhl gehauen, was in Java möglich ist.... Bevor ich dieses Spiel gesehen habe, war ich auch immer der Meinung, dass Java lahm ist aber das hat mich vom Gegenteil überzeugt und mir gezeigt, dass es alles nur Vorurteile sind...

Mittlerweile habe ich Java als sehr schöne Sprache kennengelernt... ich arbeite oft mit Eclipse und erstelle kleine Handy-Applikationen und Spiele... und habe noch nie unter mangelnder Performace der IDE gelitten... Vom flüssigen arbeiten absolut mit Delphi7 zu vergleichen, und die error checkings etc sind Delphi2005 mehr als ebenbürtig, aber das mögen auch meine persönlichen Eindrücke sein ....

Aber um auf die grundlegende Frage zu kommen:
Es gibt keine Programmiersprache, die "besser" ist als eine andere, da es immer auf das Einsatzgebiet der Applikation ankommt ...

gruß
-FastJack2

[edit]viele viele Tippfehler....[/edit]

[md_mse]

Zitat:

Zitat von FastJack2

...Ein sehr schönes Beispiel, dass Java Apps auch sehr performant laufen können findet man hier: www.chromethegame.com Ich habe das Spiel selbst angespielt und mich hat es echt vom Stuhl gehauen, was in Java möglich ist.... Bevor ich dieses Spiel gesehen habe, war ich auch immer der Meinung, dass Java lahm ist aber das hat mich vom Gegenteil überzeugt und mir gezeigt, dass es alles nur Vorurteile sind...[/edit]

Wenn man bedenkt das Java dafür nur Native Methoden verwendet, ist das auch klar...
Je komplexer eine Java-Applikation wird, desto langsamer wird sie. Und wenn man auch noch Swing benutzt, ist man eh angearscht... Man erstelle nur eine Maske mir ca. 20 Eingabefeldern unterschiedlicher Art und schon dauert das Starten über 1000 ms bei 900 MHz (ohne jeglichen Code, der nicht zu Swing gehört)!
Der Speicherverbrauch einer Primitiven Applikation ist auch gigantisch.

Java ist eine schöne Anfänger-Programmiersprache, die einem das OOP Prinzip näher bringt, aber nichts für Ernste Angelegenheiten, zumindest so lange nicht, bis jeder eine Cell-CPU und 1 GB RAM im Rechner sitzen hat...

Ich glaube Java ist keine Programmiersprache für Programmierer die was von sich halten ;)

Edit: Wobei ich mir wünschen würde, dass es Eclipse auch für Delphi gäbe :)

[Robert_G]

hmpf? :shock:

Ich glaube, bevor du hier rumpupst solltest du dich über so nette Spielereien wie SWT vertraut machen. ;) SWT ist in keinem Maße langsamer als die Widgets der API des darunterliegenden OS. (Sind ja diese Widgets :mrgreen: )
Swing ist alt und lahm, das ist wahr. Aber seit Eclipse hat man mit SWT ein prima Toolkit zur Hand. ;)

Und bevor es .Net gab, dürfte Java die einzige sinnvolle Plattform für Webservices gewesen sein. Ab einer gewissen Komplexizität ist eine VM einfach die bessere und kostengünstigere Plattform.

[r_kerber]

Zitat:

Zitat von Robert_G

Ich glaube, bevor du hier rumpupst solltest du dich über so nette Spielereien wie SWT vertraut machen. ;) SWT ist in keinem Maße langsamer als die Widgets der API des darunterliegenden OS. (Sind ja diese Widgets

Aber: SWT ist nicht mehr 100%ig plattformunabhängig, da Spezifika des jeweiligen OS abgebildet werden (z.B. OLE) und der Zugriff auf das grafische Subsystem des jeweiligen OS erfolgt (zumindest teilweise) an der Standard JVM vorbei. Das ist z.B. auch ein Grund, warum Java-Puristen die SWT ablehnen!

Zitat:

Und bevor es .Net gab, dürfte Java die einzige sinnvolle Plattform für Webservices gewesen sein.

Falls Du wirklich Webservices meinst und nicht Webanwendungen mittels EJB und/oder JSP, dann irrst Du gewaltig. Die Webservices wurden mit .net eingeführt und erst viel später auf Java aufgepfropft!
Nachtrag: Delphi/Kylix hat die Entwicklung von Webservices auch schon lange vor Java unterstützt.

[md_mse]

Zitat:

Zitat von Robert_G

Ich glaube, bevor du hier rumpupst solltest du dich über so nette Spielereien wie SWT vertraut machen. ;) SWT ist in keinem Maße langsamer als die Widgets der API des darunterliegenden OS.

Lol... SWT ist mir natürlich auch bekannt, warum sollte Eclipse für ein Java Programm so schnell sein? Währen die SWT Widgets nur mit Java Programmiert... Naja, ist halt wieder die gleiche Sache wie mit Chrome, mit Nativen Libraries geht halt alles schnell. Also pups du nicht rum :)

[Robert_G]

Zitat:

Zitat von r_kerber

Falls Du wirklich Webservices meinst und nicht Webanwendungen mittels EJB und/oder JSP, dann irrst Du gewaltig. Die Webservices wurden mit .net eingeführt und erst viel später auf Java aufgepfropft!
Nachtrag: Delphi/Kylix hat die Entwicklung von Webservices auch schon lange vor Java unterstützt.

Ich meinte eigentlich JSP/EJB, aber tatsächlich... Ich hatte mal wieder vergessen, dass nicht Java die Mammi von web services ist... :oops:

Und zu SWT: Wer seinen Usern gerne eine lahme, sämtliche Einstellungen des OS ignorierende GUI... soll er doch ;)

Wenn man wirklich auch auf Plattformen muss, die SWT nicht unterstützt. Dann "ist's swing time". *gähn*

[r_kerber]

Zitat:

Zitat von Robert_G

Und zu SWT: Wer seinen Usern gerne eine lahme, sämtliche Einstellungen des OS ignorierende GUI... soll er doch ;)

Wenn man wirklich auch auf Plattformen muss, die SWT nicht unterstützt. Dann "ist's swing time". *gähn*

Und genau da sind wir beim Thema! Der vielgepriesene Vorteil von Java (die Plattformunabhängigkeit) kannst Du dann vergessen. Also kannstz Du auch gleich native W32-Anwendungen mit Delphi schreiben. Dann kannst Du auch einen um Klassen besseren GUI-Designer verwenden!

BTW: Hast Du schon mal versucht, mit Java performante Datenbank-Anwendungen zu schreiben, die große Datenmengen verarbeiten sollen? Also daß muß ich mir nun wirklich nicht antun!

[phXql]

Zitat:

Zitat von r_kerber

Zitat:

Zitat von Robert_G

Und zu SWT: Wer seinen Usern gerne eine lahme, sämtliche Einstellungen des OS ignorierende GUI... soll er doch ;)

Wenn man wirklich auch auf Plattformen muss, die SWT nicht unterstützt. Dann "ist's swing time". *gähn*

Und genau da sind wir beim Thema! Der vielgepriesene Vorteil von Java (die Plattformunabhängigkeit) kannst Du dann vergessen. Also kannstz Du auch gleich native W32-Anwendungen mit Delphi schreiben. Dann kannst Du auch einen um Klassen besseren GUI-Designer verwenden!

BTW: Hast Du schon mal versucht, mit Java performante Datenbank-Anwendungen zu schreiben, die große Datenmengen verarbeiten sollen? Also daß muß ich mir nun wirklich nicht antun!

siehe die oracle manager console. der is fast noch langsamer als der microsoft enterprise manager ;)