-
Google Applets? -> Java Applets?
Autor: snider 09.12.08 - 11:50
Sind wir bald wieder bei Java angelangt.
-
Re: Google Applets? -> Java Applets?
Autor: Merkbefreit 09.12.08 - 12:46
Ja nur das Java besser ist und keinen speziellen Browser voraussetzt..
-
Re: Google Applets? -> Java Applets?
Autor: laZee 09.12.08 - 13:19
Und deiner Ansicht nach sollen die Native Client Dinger nicht browserunabhängig sein? Sollen sie aber.
Wo hier genau der Unterschied liegt zu JAVA wird mir so genau aber auch nicht klar. Okay, Java ist ne VM, eventuell ist da Googles Ansatz anders.
Java läuft wenn du so willst auch nur auf "speziellen" Systemen, nämlich dort, wo es installiert ist. -
Re: Google Applets? -> Java Applets?
Autor: snider 09.12.08 - 13:40
FULL ack.
-
Re: Google Applets? -> Java Applets?
Autor: martinval 16.01.09 - 16:14
Ad
> Wo hier genau der Unterschied liegt....
> ... Java ist ne VM, eventuell ist da Googles Ansatz anders.
Wie ich es verstehe, sollen diese Programmstücke einen Befehlssatz einer physischen CPU voraussetzen und, da heutzutage trotz "nativem" Code nicht alle Hardware direkt angesteuert werden soll, wird es bestimmte APIs voraussetzen. Entweder die eines bestimmten Betriebssystems, ohne das es dann nicht läuft, oder Google stellt einen "kleinsten gemeinsamen Nenner" auf allen Systemen (auf denen Chrome implementiert ist) zur Verfügung - genauso wie es die Java Runtime auch macht. Nur daß Google sich vermutlich auf einen sehr kleinen Nenner (quasi "für WebClient-Zwecke") und vermutlich auf Windows, Linux und MacOS-X beschränken wird, während Java ein sehr allgemeines und umfangreiches API definiert und dies bisher auf mehr als einem Dutzend verschiedenen Systemen (teilweise mit Einschränkungen, z.B. deutlich weniger Funktionalität auf leistungsschwachen Kleinstgeräten - Micro Edition - oder "headless", also ohne GUI z.B. - auf IBM-Mainframes)
Wenn die nativen Module aber "alles mögliche" verwenden sollen, d.h. wozu sie Lust haben und was auf einem Zielsystem verfügbar ist, dann sind sie von diesem abhängig. Vom Browser müssen sie nicht abhängig sein, wenn sie für alles eigene Mechanismen und Ressourcen nützen; wollen sie die Anzeige im Browser beeinflussen, sind sie von dessen DOM und Javascript Implementierung in dem Umfang abhängig, wie sie sie nutzen. Auch Java Applets können auf DOM-Elemente und den Javascript Interpreter zugreifen; dann sind sie an der Stelle auch eventuellen Browserunterschieden ausgesetzt. Diesbez. hat man also die Wahl.
Die erwähnten strengen Regeln für Portabilität und Sicherheit dürften darauf erstens hinauslaufen, daß man die erwähnte "Runtime" von Google benutzt und nicht beliebige Betriebssystem-APIs und Browser-Konstrukte (DOM/Javascript) - jedenfalls nicht in direktem Zugriff. Also ähnlich wie Javas definierte Runtime als gemeinsamer Protabilitätsnenner. Der Performancevorteil besteht gegenüber Javascript und Flashm sicher, wohl kaum gegenüber eine Java-VM mit gutem JIT.
Zweitens werden die Regeln zwecks Sicherheit auf eine Prüfung des nativen Codes bez. verdächtiger Konstrukte hinauslaufen, die Sicherheitslücken ausnutzen könnten und daher wohl nicht vom (nicht immer vertrauenswürdigen) Lieferanten durchgeführt werden können. Java löst das, indem es einen Bytecode für eine VM vorschreibt, der mit seiner einfacheren Struktur viel leichter geprüft werden kann als beliebige Folgen von CPU-Behfehlen einer "normalen" CPU. Diese Bytecodeverifikation wird also immer beim Laden ausgeführt, und wenn ich dem Verifyer meiner VM nicht trauen kann, den ich selbst installiert habe, wem dann?
Für "native Geschwindigkeit" muß nun ein JIT-Compiler anschließend den Bytecode übersetzen und optimieren. Fragt man bei einem ein wenig länger laufenden Programm die Zeit ab, die der JIT verbraucht hat, so sieht man, daß das ein recht kleiner Prozentsatz ist; bemerkbar macht sich nur der Speicherverbrauch für die raffinierten Optimierungen und deren Laufzeitstatistiken. Performanceprobleme rühren meist von anderen Ursachen her, nicht von der Dummheit oder Langsamkeit des JIT.
Wie Google den nativen Code, der ja viel mehr anstellen kann als für logisch eingeschränkten Bytecode definiert, beim Laden effektiv prüfen will, ist mir unklar. Auch welche Einschränkungen sie dabei machen, um ähnlich wie bei Bytecode den Vorgang zu vereinfachen, und wie Entwickler das befolgen können (wird eine Modifikation in den GCC eingebaut, die einem diese Arbeit abnimmt? Wieviel weniger performant wird das Kompilat dadurch?)
Im Grunde genommen muß Google hier eine neue Technik für einen Zweck aus dem Boden stampfen, exakt für den mit den Java Runtimes bereits ein ausgereiftes Konzept mit mehreren bestens getesteten und verbreitet installierten Implementationen besteht. Am wahrscheinlichsten scheint mir, daß das neue Produkt unter diesem Druck an Unreife und vor allem Unsicherheit leiden wird und versuchen wird, die angeblichen Performancvorteile in den Vordergrund zu stellen. Dabei wird es egal sein, worauf diese beruhen, d.h. wenn man einfach mehr Gebrauch von z.B. Hardwarebeschleunigung macht und imm übrigen die Anwender hinhält, bis stärkere Maschinen den Markt erobern, so erfüllt das auch seinen Zweck. Aber genau dasselbe wurde ja auch bei Java gemacht, man ist also bei Google mit einer "me too"-Lösung einfach zum Hinterherhecheln verdammt, falls einem nichts einfällt, wie man werbetechnisch den Anwendern einen nicht wirklich vorhandenen "Vorteil" oder ein "Alleinstellungsmerkmal" einreden kann. Wenn das nicht gelingt, flopt die Sache eben. Aber so spielt sich das Marktgeschehen ja immer ab. my 2c.



