🚀 go-pugleaf

Arno Welzel schrieb im Newsbeitrag
> Ein Servlet wird sofort umgewandelt, nicht erst nach
> mehreren Aufrufen.

So dachte ich eigentlich auch - zumal seit 1998 oder 1999 der JIT 
fester Bestandteil der JVM wurde, soweit ich mich noch erinnere. F�r 
PHP gibt es �brigens auch diese Form der �bersetzung -> Zend-Engine.

> Allerdings ist "nativer Code" eben auch erst mal nur Bytecode
> f�r die VM. Welche Server wandeln den der Bytecode nochmal
> weiter in echten nativen Maschinencode um und halten den
> auch so f�r sp�tere Aufrufe vor?

Moment - wenn JIT, dann Maschinencode und nicht Bytecode! Allerdings 
ist ja bei den Servlets die Sache noch etwas komplizierter, da hier 
die Kompilierung von Java- nach Bytecode ebenfalls automatisiert 
stattfindet bzw. stattfinden kann (zumindest bei JSP). Wir haben also 
das Ph�nomen �hnlich wie bei ASP.NET, dass der Webserver so einiges im 
Hintergrund zu machen hat und nicht nur mit dem Garbage Collector 
besch�ftigt ist ... da sind manche andere Konzepte etwas mehr 
geradlinig und verbraten deshalb weniger CPU.

Bei ASP.NET ist es ab dem IIS 6.0 so, dass der kompilierte 
Maschinencode separat vorgehalten wird, bei den �brigen Komponenten 
ist dies bei den Assemblies auch der Fall. Es gibt dort auch die 
Option, manuell den Maschinencode bei der Installation zu erzeugen, so 
dass sp�ter beim ersten Aufruf die implizite Kompilation wegfallen 
kann.

Bei diesen Assembly-Geschichten kommt man dann aber noch in eine 
andere Komplexit�t, die der Abh�ngigkeit der Objekte untereinander. 
Ist auch 'ne nette Sache, wenn man solche Konzepte nicht nur auf dem 
Web-, sondern auch auf dem Datenbankserver hat. Dort l�uft ja Java 
(bei Oracle) bzw. .NET (bei Microsoft) auch seit geraumer Zeit f�r die 
Stored Procedures ...

>> Es mag zwar Scriptsprachen geben die schnell zu Bedeutung
>> gekommen sind, aber sicher nicht zu dem Marktanteil von Java.
> In Teilbereichen vielleicht - in PHP oder Perl lassen sich nur 
> schlecht Handy-Spiele schreiben ;-)

1996 pr�sentierten sie noch stolz die Java-getriebene Kaffeemaschine 
bei der "Java One". Da war noch Java als skalierbare L�sung von 
Kaffeemaschine bis zum Cluster-Server im Gespr�ch. Dementsprechend 
gibt es die JVM in unterschiedlicher Auspr�gung und mit 
unterschiedlichen Klassenbibliotheken f�r jeden Geschmack. Tatsache 
ist aber auch, dass der lange versprochene Mikroprozessor von Sun mit 
direkter Abarbeitung von Java-Bytecode eine Wunschvorstellung war ... 
letzten Endes hat man heute in manchen ARM-Varianten mit "Jazelle" 
das, was Sun vollmundig versprochen hatte.

> Aber bei Webservern?
> Ich mag PHP zwar auch nicht besonders [...]

PHP ist krank. Das Vorhandensein von "===" und "!==" ist einfach nur 
Wahnsinn.

> [...] - aber allein die schiere Masse an fertigen L�sungen
> auf PHP-Basis, angefangen bei CMS (Typo3, Joomla, WordPress etc.),
> Wikis (MediaWiki, DokuWiki etc.) und Forensoftware (vBulletin,
> PHPbb etc.) bis hin zu Groupware-L�sungen (PHProject etc.) und 
> Systemen zur Webserver-Verwaltung (Plesk, Confixx etc.)
> kann man nicht gerade als "geringen Marktanteil" ansehen.

Mich hat schon immer gest�rt, dass es keine "simple" L�sung f�r Java 
auf dem Web-Server gab. Nat�rlich ist es sch�n, wenn man dank Trennung 
gut skalieren kann. Aber warum kann es nicht ein einfaches Plugin f�r 
den Apache geben, das direkt per JNI Java-Servlets ansprechen kann? 
Warum Tomcat? Oder warum gleich einen Web-Server direkt in Java 
geschrieben von Sun? (Der dann genauso grottenlahm ist/war, wie die 
Sun Entwicklungsumgebung, die komplett in Java geschrieben war ...)

Das, was PHP auszeichnet im Gegensatz zu ASP.NET oder JavaServlets 
oder JSP ist, dass es Hacker-freundlich ist. Und dass es sich nahtlos 
in den Code der Seite reinbasteln l�sst, ohne dass man sich zig 
Gedanken machen muss, wie man beide verheiratet. Oftmals sind es ja 
nur Kleinigkeiten, die man umsetzen muss, und das Design der Seite 
findet ja wo ganz anders statt. Aber so richtig gut ist halt PHP auch 
bei kleinen bis mittleren Systemen, wo der Ressourcenbedarf deutlich 
niedriger ist als bei Java oder ASP.NET (naja, letzteres ist auch 
recht gut).

Gru�, Dirk