Hallo,
IMHO ist diese gesamte Java-Architektur sehr langsam und
haeufig auch inkonsistent. Meine 128MB RAM reichen zur
Entwicklung auf keinen Fall... unter einem Gigabyte sollte
man da nicht anfangen.
Ich kenne jetzt von Java nur die Cleintseite, die Serverseite kann ich daher nicht beurteilen. Aber wenn man kein Swing (das ist die eigentliche Bremse) verwendet, dann ist Java schneller in der Ausführung an sich als PHP. Nur halt das Laden dauert länger. Java läuft sogar auf 133er-Pentium-I noch recht flott, wie gesagt: ohne Swing.
Kann ich nur bestätigen. Das Problem mit Geschwindigkeit und Resourcenverbrauch gibt es nur in Zusammenhang mit Swing. Ok bisschen Overhead hat man auch ohne Swing dadurch das man die VM mitschleppen muss aber es hält sich in Grenzen. Vorallem nimmt das wenn die VM erstmal geladen ist nicht mehr so deutlich zu wenn mehrere Servlets hinzukommen.
Wir verwenden hier ebenfalls Tomcat auf einem Pentium-PC und haben keine Probleme. Der RAM-Verbrauch der gesamten Servlet-Engine (mit Servlets) liegt bei um die 50MB und das finde ich ganz moderat.
Und durch Just-In-Time Compiling liegt Java-Code sehr gut im Rennen.
Wenns doch mal eng wird dann unterstützt der Tomcat auch Load-Balancing.
Ich habe in den letzten Monaten Java auf der Clientseite "kenngelernt" und finde, dass die Vorurteile, die ständig kommen, ungerechtfertigt sind.
Ja die Geschwindigkeit läßt schon zu wünschen übrig bei der Verwendung Swing. Die Applikation fühlt sich einfach nicht an wie eine Native, dadurch das es manchmal etwas behäbig und hakelig zugeht.
Oftmals liegt die Schuld aber am Programmierer. Swing ist eine elegante API. Aber auch recht komplex. Damit umzugehen, ist nicht so einfach.
Eine Alternative (neben AWT) wäre übrigens das SWT (als OpenSource verfügbar). Das verwendet wie AWT native Peers und zeichnet nur die Sachen selbst, die die entsprechende Plattform nicht zur Verfügung stellt. Das ist natürlich eine prima Sache. Denn das Look & Feel passt sich wirklich der jeweiligen Plattform an, so dass sich der Anwender zuhause fühlt. Selbst Themes werden berücksichtigt (siehe WinXP). Obendrein ist das ganze Resourcenschonender (RAM und CPU).
Nachteil aus Programmierersicht: Die API ist nicht ganz so elegant. Vorallem wie man C++-mäßig wieder dazu verdonnert, sich um belegte Resourcen selbst zu kümmen (das heißt es gibt Destruktoren für diese Elemente; GarbageCollection funktioniert damit nicht). Auch die Trennung von Daten und Darstellung (MVC) wie in Swing beispielsweise mit TableModel und JTable sind so in SWT nicht realisiert.
Aber immerhin. Eine Alternative.
Nur das SDK könnte kleiner sein, 40 MB sind wohl doch etwas viel...
Beim SDK sehe ich nicht das Problem. Das ist eh nur für Entwickler/Administratoren. Für die reine Ausführung reicht ja das JRE. Aber selbst die ca.10MB sind eigentlich noch recht fett für Modem/ISDN-Benutzer. Ok. Bei verkauften Applikationen kann man ja das noch mit auf der CD ausliefern. Aber für Applets und Freeware wird man nicht viel Freiwillige finden, die sich das downloaden.
ups .... ist ja wieder mehr geworden als ich wollte. Vorallem nicht ganz zum Thema. Naja ok.
Gruss
MichaelB