1. Foren
  2. Kommentare
  3. Internet
  4. Alle Kommentare zum Artikel
  5. › Webassembly: Bytecode fürs Web ist…

Na, dann hätte man Java Applets beibehalten können

  1. Thema

Neues Thema Ansicht wechseln


  1. Na, dann hätte man Java Applets beibehalten können

    Autor: HansiHinterseher 01.11.16 - 14:39

    Oh man, Geschichte wiederholt sich aber auch immer wieder.
    Jetzt wird also eine Bytecode-Engine in die Webbrowser direkt eingebaut. Also nichts anderes was wir schon mal mit Java Applets hatten, nur das es da noch ein Plug-in war. Aber am Ende des Tages ist es doch das gleiche.

    Die Webbrowser werden immer mehr zu dem, was Flash, Shockwave und JavaApplets probiert hatten. Aber es war den Webbrowser-Herstellern ein Dorn im Auge.

  2. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: RicoBrassers 01.11.16 - 15:16

    Den Browser-Herstellern war es ein Dorn im Auge, dass der ganze Kram etliche Sicherheitslücken hatte und immer wieder neue dazugekommen sind.
    Und das hat nichts damit zu tun, dass es Bytecode ist.

  3. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: Stebs 01.11.16 - 15:21

    HansiHinterseher schrieb:
    --------------------------------------------------------------------------------
    > Aber am Ende des Tages ist es doch das gleiche.
    Nein, definitiv nicht das gleiche, wasm brauch z.B. keinen JIT-Compiler, keinen Garbage-Collector etc.

  4. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: zilti 01.11.16 - 17:35

    Doch, natürlicht braucht wASM einen JIT-Compiler (auch Bytecode muss noch übersetzt werden und läuft nicht direkt auf dem Prozessor), und einen GC erst recht - ich glaube nicht, dass irgendjemand Bock auf manuelle Speicherverwaltung im Browser hat.

  5. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: Stebs 01.11.16 - 17:48

    zilti schrieb:
    --------------------------------------------------------------------------------
    > Doch, natürlicht braucht wASM einen JIT-Compiler (auch Bytecode muss noch
    > übersetzt werden und läuft nicht direkt auf dem Prozessor), und einen GC
    > erst recht - ich glaube nicht, dass irgendjemand Bock auf manuelle
    > Speicherverwaltung im Browser hat.
    Ja, das mit dem JIT-Compiler war Quatsch.
    Einen Garbage Collector soll es evtl. später geben, um auch Sprachen wie Java und C# zu unterstützen.

    "No built-in automatic garbage collector following you around and stopping you periodically while it cleans up your scraps."
    > https://medium.com/javascript-scene/what-is-webassembly-the-dawn-of-a-new-era-61256ec5a8f6

    asm.js nutzt ja afaik auch keinen automatischen Garbage-Collector!?



    2 mal bearbeitet, zuletzt am 01.11.16 17:50 durch Stebs.

  6. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: Mephir 02.11.16 - 04:49

    Stebs schrieb:
    --------------------------------------------------------------------------------
    > asm.js nutzt ja afaik auch keinen automatischen Garbage-Collector!?

    "asm.js" selbst nicht; wie auch? Ist ja auch nur eine "Spezifikation".
    Jedoch besitzen die gängigen JS-Engines, auf denen der Code ausgeführt wird, in der Regel alle einen Garbage-Collector.

    > Nein, definitiv nicht das gleiche, wasm brauch z.B. keinen JIT-Compiler,
    > keinen Garbage-Collector etc.

    Gerade im Webumfeld würde ich auf einen GC nicht verzichten.
    Allein schon aus Anwendersicht wäre es eher von Vorteil, bei evtl. einem einfachen Seitenaufruf nicht einen Haufen Speicherleichen zu fabrizieren.



    2 mal bearbeitet, zuletzt am 02.11.16 04:54 durch Mephir.

  7. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: RicoBrassers 02.11.16 - 08:27

    Stebs schrieb:
    --------------------------------------------------------------------------------
    > Ja, das mit dem JIT-Compiler war Quatsch.
    > Einen Garbage Collector soll es evtl. später geben, um auch Sprachen wie
    > Java und C# zu unterstützen.

    Die Begründung, warum es einen GC später geben soll, ist ebenfalls Quatsch.
    Man führt im Browser dann ja keine Java-/C#-Programme aus, sondern der Code wird vom Programmierer z.B. von Java-Syntax in "Wasm" (bzw. entsprechenden Bytecode) übersetzt. Das heißt, dass die Features, die z.B. von der Java-VM geboten werden, eben nicht vorhanden sein müssen, da es sich nicht um ein Java-Programm handelt, auch wenn es letztlich in Java geschrieben wurde. ;)

    Im Grunde ist es ähnlich wie mit z.B. TypeScript. Man schreibt zwar in TypeScript, aber ausgeführt wird lediglich die nach JavaScript übersetzte Datei, weil Browser kein TypeScript können. ;)

  8. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: Kleine Schildkröte 02.11.16 - 08:49

    Mephir schrieb:
    --------------------------------------------------------------------------------
    > Stebs schrieb:
    > ---------------------------------------------------------------------------
    > -----
    > > asm.js nutzt ja afaik auch keinen automatischen Garbage-Collector!?
    >
    > "asm.js" selbst nicht; wie auch? Ist ja auch nur eine "Spezifikation".
    > Jedoch besitzen die gängigen JS-Engines, auf denen der Code ausgeführt
    > wird, in der Regel alle einen Garbage-Collector.
    >
    > > Nein, definitiv nicht das gleiche, wasm brauch z.B. keinen JIT-Compiler,
    > > keinen Garbage-Collector etc.
    >
    > Gerade im Webumfeld würde ich auf einen GC nicht verzichten.
    > Allein schon aus Anwendersicht wäre es eher von Vorteil, bei evtl. einem
    > einfachen Seitenaufruf nicht einen Haufen Speicherleichen zu fabrizieren.

    ? Warum produzierst du da Speicherleichen? Jede Seite hat ihren eigenen Heap, der freigegeben wird, wenn die Seite nicht mehr benötigt wird. Schlimmer ist da, wie man sich das Speichermanagement von Nutzersicht vorstellen muss: 20 offene Tabs, ein Tab zieht Speicher über Gebühr... OutOfMemory -> Wie will man das dem Nutzer erklären. Und wenn die dann plötzlich Spiele und Apps im Browser(WTF?) ausführen, was dann?

    Das wird ewig dauern bis die neuen Sandbox/VMs (Jeder Browser-Hersteller eine eigene(?)) einigermaßen Sicher sind.

  9. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: Kleine Schildkröte 02.11.16 - 08:55

    HansiHinterseher schrieb:
    --------------------------------------------------------------------------------
    > Oh man, Geschichte wiederholt sich aber auch immer wieder.
    > Jetzt wird also eine Bytecode-Engine in die Webbrowser direkt eingebaut.
    > Also nichts anderes was wir schon mal mit Java Applets hatten, nur das es
    > da noch ein Plug-in war. Aber am Ende des Tages ist es doch das gleiche.

    Java hatte verloren, da Sun und Microsoft sich nicht einigen konnten bzw. Microsoft kein Interesse daran hatte, dies auf Lange sicht zur dominanten Programmiersprache werden zu sehen, während Sun die Spezifikationen durchsetzte. Am Ende der Entwicklung hat Microsoft plötzlich C# aus dem Hut gezogen.

    Das zweite Problem war, dass Java nicht von Anfang an, die Sprache im Web war. So wie es bis dahin implementiert wurde (plugin) war es immer ein Fremdkörper wie ein Video.

    > Die Webbrowser werden immer mehr zu dem, was Flash, Shockwave und
    > JavaApplets probiert hatten. Aber es war den Webbrowser-Herstellern ein
    > Dorn im Auge.

    Exakt. Das erste Problem war der Fehler von Sun, die Bildschirmausgabe lange Zeit nicht optimal und effizient hinzubekommen und gleichzeitig die professionellen Designer und Entwickler nicht mit geeigneten Werkzeugen auszustatten. Ich habe nie verstanden, warum Sun nicht Flash zur Seite gedrängt hat und ebenso hab ich nie verstanden, warum dieses Swing kam und gleichzeitig sie Dinge wie SWT/JFace nicht selbst machten. AWT hätte soviel mehr werden müssen und es ging in die richtige Richtung. Anstatt Swing hätten sie AWT aufboren müssen mit einem Emulationsrenderer und native-komponenten wenn möglich.

  10. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: Mephir 02.11.16 - 09:03

    Kleine Schildkröte schrieb:
    --------------------------------------------------------------------------------
    > ? Warum produzierst du da Speicherleichen? Jede Seite hat ihren eigenen
    > Heap, der freigegeben wird, wenn die Seite nicht mehr benötigt wird.
    Ich rede auch nicht vom "nach dem Schließen", sondern während der "Ausführungszeit".

    > Schlimmer ist da, wie man sich das Speichermanagement von Nutzersicht
    > vorstellen muss: 20 offene Tabs, ein Tab zieht Speicher über Gebühr...
    Wieso? Standardconfig vom Fiferox z.B. sagt max. 2GB adressierbarer Speicher pro Tab.
    Und wenn der voll ist, geht halt nix mehr.
    Und wer 30 Cookieclicker-Tabs offen hat ist selber schuld..

    > OutOfMemory -> Wie will man das dem Nutzer erklären. Und wenn die dann
    > plötzlich Spiele und Apps im Browser(WTF?) ausführen, was dann?
    Warum "WTF"? "Spiele und Apps" im Browser auszuführen ist doch legitim.

  11. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: Trollversteher 02.11.16 - 09:37

    >Die Begründung, warum es einen GC später geben soll, ist ebenfalls Quatsch.
    Man führt im Browser dann ja keine Java-/C#-Programme aus, sondern der Code wird vom Programmierer z.B. von Java-Syntax in "Wasm" (bzw. entsprechenden Bytecode) übersetzt. Das heißt, dass die Features, die z.B. von der Java-VM geboten werden, eben nicht vorhanden sein müssen, da es sich nicht um ein Java-Programm handelt, auch wenn es letztlich in Java geschrieben wurde. ;)

    Nein, die Begründung ist natürlich kein Quatsch - Java und C# Programme verlassen sich auf einen Garbage-Kollektor, und bringen daher keine eigene Speicherverwaltung mit. Um diese Programme nach Wasm übersetzen zu können, muss also ein garbage collektor in irgendeiner Form vorhanden sein.

  12. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: zilti 02.11.16 - 10:24

    Aber in etwa so sinnvoll wie mit dem Staubsauger eine Tasse Kaffee zu kochen.

  13. Re: Na, dann hätte man Java Applets beibehalten können

    Autor: theonlyone 02.11.16 - 10:26

    Trollversteher schrieb:
    --------------------------------------------------------------------------------
    > >Die Begründung, warum es einen GC später geben soll, ist ebenfalls
    > Quatsch.
    > Man führt im Browser dann ja keine Java-/C#-Programme aus, sondern der Code
    > wird vom Programmierer z.B. von Java-Syntax in "Wasm" (bzw. entsprechenden
    > Bytecode) übersetzt. Das heißt, dass die Features, die z.B. von der Java-VM
    > geboten werden, eben nicht vorhanden sein müssen, da es sich nicht um ein
    > Java-Programm handelt, auch wenn es letztlich in Java geschrieben wurde. ;)
    >
    > Nein, die Begründung ist natürlich kein Quatsch - Java und C# Programme
    > verlassen sich auf einen Garbage-Kollektor, und bringen daher keine eigene
    > Speicherverwaltung mit. Um diese Programme nach Wasm übersetzen zu können,
    > muss also ein garbage collektor in irgendeiner Form vorhanden sein.

    Grundsätzlich kannst du in Java ja auch manuell deinen speicher Verwalten.
    Den Garbage Collector manuell aufzurufen macht in aller Regel keinen Sinn, auch kann man alle seine Objekte schön per Hand abbauen (sich praktisch einen Destructor zusammen meiseln).

    Aber sobald man automatischen GC hat ist es einfach sinnvoll den auch zu benutzen, damit man sich eben um die eigentlichen Probleme kümmern kann.

  1. Thema

Neues Thema Ansicht wechseln


Um zu kommentieren, loggen Sie sich bitte ein oder registrieren Sie sich. Sie müssen ausserdem in Ihrem Account-Profil unter Forum einen Nutzernamen vergeben haben. Zum Login

Stellenmarkt
  1. noris network AG, Nürnberg, München, Aschheim, Berlin
  2. SURFBOXX IT-SOLUTIONS GmbH, Rostock
  3. Merz Pharma GmbH & Co. KGaA, Frankfurt am Main
  4. Württembergische Gemeinde-Versicherung a.G., Stuttgart

Golem pur
  • Golem.de ohne Werbung nutzen

Anzeige
Hardware-Angebote
  1. täglich neue Deals bei Alternate.de


Haben wir etwas übersehen?

E-Mail an news@golem.de


UX-Designer: Computer sind soziale Akteure
UX-Designer
"Computer sind soziale Akteure"

User Experience Designer schaffen positive Erlebnisse, wenn Nutzer IT-Produkte verwenden. Der Job erfordert Liebe zum Detail und den Blick fürs große Ganze.
Ein Porträt von Louisa Schmidt

  1. Coronapandemie Viele IT-Freelancer erwarten schlechtere Auftragslage
  2. IT-Fachkräftemangel Es müssen nicht immer Informatiker sein
  3. Jobporträt IT-Produktmanager Der Alleversteher

Coronavirus und Karaoke: Gesang mit Klang trotz Gesichtsvorhang
Coronavirus und Karaoke
Gesang mit Klang trotz Gesichtsvorhang

Karaokebars sind gefährliche Coronavirus-Infektionsherde. Damit den Menschen in Japan nicht ihr Hobby genommen wird, gibt es nun ein System, das auch mit Mundschutz gute Sounds produzieren soll.
Ein Bericht von Felix Lill

  1. Corona Gewerkschaft sieht Schulen schlecht digital ausgestattet
  2. Corona Telekom und SAP sollen europaweite Warn-Plattform bauen
  3. Universal Kinofilme kommen früher ins Netz

Golem on Edge: Wo Nachbarn alles teilen - auch das Internet
Golem on Edge
Wo Nachbarn alles teilen - auch das Internet

Mehr schlecht als recht arbeiten zu können und auch nur dann, wenn die Nachbarn nicht telefonieren - das war keine Dauerlösung. Wie ich endlich Internet in meine Datsche bekommen habe.
Eine Kolumne von Sebastian Grüner

  1. Anzeige Die voll digitalisierte Kaserne der Zukunft
  2. Keine Glasfaser, keine IT-Kompetenz Schulen bemühen sich vergeblich um Geld aus dem Digitalpakt
  3. Kultusministerien Schulen rufen kaum Geld aus Digitalpakt ab