Ist Java wirklich so langsam?
-
warum sollte Java nicht laufen, wenn man Linux hat? Und für FreeBSD gibt es doch
http://www.freebsd.org/java/Das ist korrekt, es muss installiert werden!
mfg
v R
-
Sollte nicht gerade das der grosse Pluspunkt von Java sein, Plattform-unabhänginge
GUI-Programmierung??Hmmm...es laeuft zwar nicht unter nem Browser, aber dann kannste auch QT, gtkmm,
gtk oder wxWindows nutzen, wenn de Plattform-unabhaengig ne GUI programmieren
willst.mfg
v R
-
Jetzt möchte ich mal die Infos und Erfahrungen loswerden, die ich über Java habe, die aber überhaupt nicht zusammenpassen:
Im Fernsehen sah ich mal einen Sprecher von Siemens, der behauptete, dass kleinere, zeitkritische und hardware nahe Applikationen bei Siemens ind C++ geschrieben werden, dass bei größeren Projekten aber JAVA der Vorzug gegeben wird. Begründet wurde dies mit der schlechteren Performance und dem stabileren Verhalten von JAVA. (Vielleicht sind Siemens-Leute im Forum, die diese Aussage bestätigen oder widerlegen können?)
Hier im Forum gibt es immmer wieder Stimmen, die sagen, dass JAVA-Applikationen fast genauso schnell sind wie C++ - Applikationen. Dies widerspricht mal der Aussage des Siemens-Sprechers. Zum zweiten hab ich mir vor einiger Zeit aus Interesse mal Forte4Java auf meinen Rechner gespielt und versucht damit zu arbeiten. Wenn ich Forte gestartet hab, konnte ich mir einen guten Tee machen und musste ich dafür sorgen, dass das Start-Bild nicht im Vordergrund steht, sonst hängte sich der Rechner auf. Performance ging so einigermaßen, aber während des Arbeitens verlor die IDE immer mehr Funktionen. Neustart, mit der entsprechenden Wartezeit, war dann wieder nötig um wieder alles nutzen zu können.
Dann arbeite ich ganz gern mal kostenfrei und legal mit OpenOffice oder dem alten Star-Office. Zu hause nehm ich mir die Zeit, bis das geladen ist und ich nehme auch die Abstürze(! sind aber imho bei Word auch nicht besser) in Kauf. Die Wartezeit ist aber schon oft lang.
Was wieder auf einem anderen Blatt steht ist die Theorie. Ich hab auch einiges über JAVA und JAVA-Programmierung gelesen. Wenn das alles so stimmt und auch umgesetzt wird, dann sollte JAVA eigentlich ohne Absturz laufen.
Irgendwo bleibt nun die Frage: Lügt irgendwer oder sind JAVA-Programmierer einfach schlechter ausgebildet bzw. unvorsichtig. Liegt es vielleicht daran, dass JAVA durch Swing oder ähnlches in die Knie gezwungen wird? So geartete "Argumente" hab ich auch schon gelesen. Aber auch die Benutzeroberfläche gehört für den Anwender zum Programm und es hilft nichts, wenn superschneller Code nicht zur Anwendung kommt, weil der Benutzer nich warten möchte, bis sich die Oberfläche endlich aufgebaut hat.Bin für Infos immer zu haben
Ein verwirrter Kauz01
-
Also solange eine Sprache nicht im für das vorliegende System ausführbaren Maschinencode vorliegt, sondern nur in einem abstrakten Bytecode, der interpretiert werden muß, kann diese Sprache NIEMALS schneller sein, als ein entsprechendes anderes Programm, welches laufzeitfertig bereitsteht. Es sei denn, es hat jemand ohne Sachverstand bzw. ausreichende Kenntnisse programmiert.
Wenn ein JAVA-Programm vor dem Erststatt einmalig compiliert werden würde, sähe die Sache sicher auch anders aus. Ob aber der Weg von JAVAJava-Source --> Bytecode --> Interpreter, der Programm ausführt
schneller ist als C/C++
Source -> ausführbares Programm
sieht wohl jeder selber.
Letztlich hängt aber auch viel vom Programmierer ab. Durch optimale Programmierung kann man schon einiges rauskitzeln. Wenn man jedoch zwischen seinem Programm und der Oberfläche, die der Anwender sieht, zig Programm-Schichten dazwischen hat, muß natürlich die Geschwindigkeit leiden! Dann hängt vieles davon ab, wie gut diese einzelnen Schichten programmiert sind.
Um das Problem zu umgehen, hat MS ja vor ettlichen Jahren ActiveX bei Spielen aus der Taufe gehoben und damit den modernen Spielen den Weg auf Windows geöffnet. Ansonsten würden wir heute noch unsere Spiele aus DOS heraus laufen lassen, weil nur Leute ohne Ahnung ein ruckelndes PacMan Spiel auf Windows gut finden würden.
Was ich an den OOP-Sprachen etwas bemängle, ist der sorglose Umgang mit Ressourcen. Man klickt halt ein bissle was zusammen, schreibt ein paar Ereignisbehandlungsroutinen und fertig sind mit 500 Programmzeilen riesen Programmonster von hunderten von KBytes.
Wenn man sich mal alte C64, Amiga oder auch DOS-Programme ankuckt, die sogar damals in Zeiten knapper Speicher speicherresident waren, so weiß man, was ich meine. Klar sind auch die Ansprüche an die Software größer geworden. Keine Frage. Aber den Druck, immer schneller Software zu schreiben und auf den Markt zu werfen, ist nicht zwingend ein Fortschritt! Mir reicht mein Word97 vollkommen aus und ich wüßte nicht, welches Forummitglied hier wirklich WordXP tatsächlich und häufig ausreizt! Viele legen halt Wert auf Animationen und coole Oberflächen, bei denen der Prozessor halt entsprechend gefordert wird. Und wenn man bei der Software Version 123.0 keinen Markt für neue Software mehr hat, dann macht man die halt mit Marketing, Support-Politik und Marktmacht einen neuen Markt auf. Man suggeriert den Leuten einfach, daß es unendlich super toll ist, diese neuste Version, die 10 Sachen mehr kann, als die alte Version mit 820 Funktionen, zu kaufen. Schließlich gibt es auch ein neues Look & Feel, wie man es schon vor 5, 6 Jahren schonmal hatte....
Und schließlich will die Hardware-Industrie auch ihr Zeugs verkaufen....Erinnert mich oft an das Covern alter guter Musiktitel. Im Grund das Gleiche Lied, nur ein bissel dran rumgeschraubt und alle finden das Megatoll und kaufen fleißig die CD für 49€ dazu...
Aber stellt Euch mal vor, ein C++ Programmierer müßte heute in C++ das Programm für die Mondfähre von 1969 schreiben! (Speicher war glaub ich 8 KByte). Da sieht man schnell alt aus. Komischerweise hat das aber damals auch ohne OOP mit sorgfältiger Planung ganz gut geklappt! Allerdings mußten die auch nicht ständig Betriebssysteme und Compiler nach 6 Monaten wechseln....
C++ und Java haben natürlich ihre Daseinsberechtigung und die Zeit geht weiter. Aber Java als letzte Rettung der Informatik hinzustellen, is wohl arg übertrieben. Und wer nicht vernünftig mit Zeigern umgehen kann, dürfte meiner Meinung nach sowieso nur in Basic programmieren, bis er das mal richtig gelernt hat.
-
Also jetzt mal was von mir!
Ich programmiere beruflich seit drei Jahren in Java, tag täglich! Wir entwickeln Java-Client-Applikationen, also keine Applets, die ziemlich groß sind. Im Team sind wir im Schnitt 8 Progger, Projektzeit ca. 2 Jahre. Gut, also keine Pipi-Programme.Ich selbst bin von Java nicht begeistert, ich progge in Java weil ich damit meine Brötchen verdienen kann. Denn unser Großkunde (ich wohne in Wolfsburg, welcher Kunde es ist, kann sich jeder denken) will hauptsächlich Java-Applikationen. Warum? Weil vor ein paar Jahren hier im Konzern ein paar IT-Fuzzis meinten, Java gehört die Zukunft. PENG! So, und es gibt hier bestimmt 50 Projekte, ich schätze mal ca. 80 Prozent mittlerweile in Java.
Gut, damit muß man leben. Ich motze hier zwar schon immer mal rum, das C++ besser ist, aber auf mich hört ja keiner!
Was ist mit Performance? Das kann ich leidvoll erzählen!
- Der Start der Applikationen ist nervend langsam
- Die Swing-GUI ist bei jeder komplexeren Gestaltung tierisch lahm
- Der verdammte Garbage Collector killt die Objekte zu spät, die nicht mehr genutzt werden, ergo Speicherhunger. Unter C++ kann ich selbst bestimmen wann ein Objekt gekillt werden soll.Das sind erstmal die Schwächen, die man nicht nur als Coder täglich erlebt, nein, auch der normale User MUSS damit arbeiten!
Ich könnte jetzt da weiter machen, wo ich als Coder jedesmal einen Schreikrampf bekomme. Es gibt so lustige Situationen, wo ein Kollege in ein Combox-Model oder Treenode-Model einfach mal einen String einfügt. Obwohl wir da eigene komplexere Objekte reinwerfen. Tja, und dann knallts natürlich zur Laufzeit, und man wundert sich warum das ganze Ding einem Exceptions um die Ohren haut. Wo bleibt die Typsicherheit?
Was ganz beliebt ist, bei den überzeugten Java-Codern: Try/Catch-Blöcke! ARGH! Egal wo, egal wie, hauptsache try/catch! Sauberes Coden um Exceptions überhaupt ansatzweise zu vermeiden, kennen Java-Coder nicht.
Eclipse ist das beste Beispiel. Es benutzt das native GUI von der jeweiligen Plattform. Mit Eclipse kann man deshalb einigermaßen vernünftig arbeiten, da der Schwachpunkt namens Swing gestrichen wurde. Aber somit ist das Thema "ohne Neucompilierung überall lauffähig" natürlich zunichte. Da kann ich genauso gut in C++ coden und wxWindows, GTK oder Qt nutzen.
Naja, ich muß jetzt weiter in Java coden.
-
Anmerkung:
Bei den oben genannten Forte, Star-Office und OpenOffice handelt es sich um die Windows-Versionen. Die dürften also schon kompiliert sein.
-
JFK! Mir scheint, du bist nicht auf dem neuesten Stand. Java-Programme werden mittlerweile native compiliert, und zwar zur Laufzeit! D.h. der JIT-Compiler (Just in Time) compiliert den Code den er gerade durchläuft in Maschinencode. Nur ist das halt auch so ne Sache, da das compilieren auch Zeit kostet, nebenbei das Prog laufen muß, kostet zus. Speicher usw. Ob der JIT alles compiliert, weiß ich nicht. Ich denke mal, er compiliert nur die Sachen, die Rechenintensiv sind.
Das C++-Programme so groß sind, hat ja nichts mit der Sprache selbst zu tun. Sie sind ja so groß, weil noch die ganzen Standard-Libs mit verbunden werden. Würde man das in Assembler auch machen, hätte man das gleiche Ergebnis. Sinnigerweise macht man das nicht, weil man in Ass direkt in den Bildschirmspeicher schreibt usw. Naja, das soll jetzt nicht das Thema sein, es würde den Rahmen sprengen.
[ Dieser Beitrag wurde am 11.07.2003 um 10:36 Uhr von Artchi editiert. ]
-
@Artchi: gut, daß meine schwäbische Firma nicht ganz so fortschrittsgeil ist und immer erst auf den Kontostand schielt, bevor irgendwelche Ex-Studenten und Möchtegern-Hellseher den laufenden Betrieb umkrempeln wollen. Was in der Wirtschaft zählt ist das Ergebnis, die Entwicklungskosten, die laufenden Kosten, die Pflegeaufwände, die Hardwarekosten und die Sicherstellung eines möglichst reibungs- und störungsfreien Betriebs. Denn wie gesagt: die IT ist nicht zum Selbstzweck da (auch wenn MS, IBM, Borland, SUN etc. das gerne so hätten).
-
Nach meinem Kenntnisstand compiliert der Java-Interpreter gar nix bzw. nicht alles. Aber da mich Java generell nicht besonders interessiert, kann das auch schon etwas veraltet sein. Da geb ich Dir recht.
-
Original erstellt von JFK:
Nach meinem Kenntnisstand compiliert der Java-Interpreter gar nix bzw. nicht alles. Aber da mich Java generell nicht besonders interessiert, kann das auch schon etwas veraltet sein. Da geb ich Dir recht.Ich kann dir garantieren, das Java seit 1.3 einen JIT hat und nativen Code zur Laufzeit erzeugt. Was ich aber nicht weiß, ist ob der JIT jede Zeile compiliert, oder sich entscheidet, was er native compiliert (es gibt ja Dinge da lohnt es sich nicht, z.B. Strings oder primitive Datentypen, da diese schon seit eh und je native von der VM verarbeitet werden).
-
Warum wird SWING nicht endlich mal schneller gemacht? Das müsste doch möglich sein.
-
Danke für die Info.
Aber ich könnte mir auch gut vorstellen, daß man jedes C++ Programm auf ein anderes System portieren kann, wenn man den Assemblercode auf den anderen Prozessor anpaßt. Na und wenn ich eine VCL nutze, die für jedes System vorhanden ist, aber die exakt gleichen Methoden hat, dann kann ich das auch mit C++ machen. Bleibt also kein Vorteil mehr für mich, was in Java zu machen.
-
Zum Schluss
Java Ist Einfach scheiße
das ist der code von Java:
scheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißeschei ßescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißesch eißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheißescheiße. Punkt
-
Original erstellt von Artchi:
Ich kann dir garantieren, das Java seit 1.3 einen JIT hat und nativen Code zur Laufzeit erzeugt. Was ich aber nicht weiß, ist ob der JIT jede Zeile compiliert, oder sich entscheidet, was er native compiliertDer JIT-Compiler wurde mit Java 1.1 eingeführt, also 1997. Seit dem wurde er natürlich in jeder Version verbessert.
Der JIT-Compiler heute entscheidet zur Laufzeit, was er kompiliert und was er optimiert. In der Praxis werden etwa 99% des Codes kompiliert.
Warum wird SWING nicht endlich mal schneller gemacht? Das müsste doch möglich sein.
Swing wird in jeder Version etwas schneller gemacht. Mit Java 1.4.2 wurden z.B. beim JFileChooser eine Menge Performance-Probleme beseitigt.
Gleiches gilt für die Startzeit der Applikationen. Auch die wird in jedem Release verringert.
[ Dieser Beitrag wurde am 11.07.2003 um 11:18 Uhr von Gregor editiert. ]
-
Java ist sogar schnell genug für Gamez. Siehe hier:
http://www.puppygames.net/index.htm
-
Naja, warum wohl? Weil es die native Grafikschnittstelle nutzt, entweder OpenGL oder unter Windows halt DirectX. Das gleiche wie bei Eclipse: es wird die native Schnittstelle benutzt.
Da bei heutigen Games mehr Power auf Grafik und Sound drauf geht (die letztendlich eh die 3D-Hardware übernimmt), als auf reinen Logic code, ist da Java auch auf 2 GHz CPUs ausreichend.
-
Original erstellt von scrontch:
D.h. man muss nach wie vor OS-spezifischen Bibliotheken nutzen, damit die GUI zügig läuft???
Sollte nicht gerade das der grosse Pluspunkt von Java sein, Plattform-unabhänginge GUI-Programmierung??
Weil plattformunabhängigen Kern-Code kann C++ auch.
übrigens gibt's GTK selbst schon für Win32, Motif etc.Hm, erklär mir dochmal bitte, wie du ohne auf die Betriebssystem-API zuzugreifen ein Fenster erzeugen willst. Bibliotheken brauchst du dafür immer, genauso wie man unter C++ auch Bibliotheken braucht, wie GTK. Das sind halt Dinge die nicht beim Softwareprodukt beizuliegen haben, sondern bei der Laufzeitumgebung.
-
Hi,
Java ist tot - es lebe Java! Inzwischen erinnert sich kaum noch jemand an die kleinen, verspielten und wenig sinnvollen Java-Applets aus der Anfangszeit des WWW. Doch jenseits der bunten Webseiten wurde Java erwachsen - und mit der Webstart-Technologie kehrt Java wieder zurück. Ausgewachsene Programme, die über das WWW aktualisiert werden, die man nicht installieren muß und die einmal geschrieben auf einer Vielzahl (äh 3, um genau zu sein) von Plattformen laufen - das ist die Software-Entwicklung im aktuellen Jahrtausend.
-
Original erstellt von <gernot>:
Hi,
Java ist tot - es lebe Java! Inzwischen erinnert sich kaum noch jemand an die kleinen, verspielten und wenig sinnvollen Java-Applets aus der Anfangszeit des WWW. Doch jenseits der bunten Webseiten wurde Java erwachsen - und mit der Webstart-Technologie kehrt Java wieder zurück. Ausgewachsene Programme, die über das WWW aktualisiert werden, die man nicht installieren muß und die einmal geschrieben auf einer Vielzahl (äh 3, um genau zu sein) von Plattformen laufen - das ist die Software-Entwicklung im aktuellen Jahrtausend.webstart? nee, ich brauch meinen texteditor nicht als applet.
-
Das sind ganz normale Java Applications die sich über WebStart bequem installieren lassen. Aber hab mich im Thread vertan. Sollte in Java ist tot.