8 ms·

What can wasm accomplish in that way that Java couldn't? I'm really confused about the hoopla.

by projektfu 4y ago

pjmlp 4y ago
Some folks have need to create startups to fulfill a need we don't know we need to have solved.
- bloppe 4y ago
  Well, unlike Java, Wasm is not the product of a for-profit company. It's a W3C standard that actually does solve many problems most people didn't realize they had. It essentially obsoletes virtualization (CTO of Docker famously said "If WASM+WASI existed in 2008, we wouldn't have needed to created [sic] Docker. That's how important it is"). It will allow the creation of a unified software ecosystem across languages (Wasm "components" are designed to allow you to e.g. import numpy into a JavaScript project. See https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type...). The virtual machine is designed from the ground up to make many types of vulnerabilities, such a stack smashing, impossible. And, as an open standard, it's not beholden to the whims and lawyers of Oracle. I'm not 100% certain the W3C working group won't end up fumbling it, but if you're not excited about wasm then you probably just don't know much about it.
  - kaba0 4y ago
    Oracle was the company that completely open-sourced OpenJDK and even their own paid support JDK is just a minor modification of the former. Java and the JVM is also among the few languages/platforms with separate specifications, and multiple completely independent implementations. If anything, Java is a much much safer bet than the oligopoly of WebKit/Blink.
  - pjmlp 4y ago
    Yet there are enough for profit companies on its genesis and foundation. As for Docker, it is basically Java Application Servers full with YAML spaghetti to the point it makes me miss Websphere 5. Or even better, mainframe and microcomputers language environments like on IBM i, z/OS and Unisys ClearPath. Maybe its founders should have learned what preceded it.
    - EUROCARE 4y ago
      The founders know very clearly what preceded it as they're working with the authors of these previous attempts (JVM, CLR, etc) to integrate their stacks with Wasm.
      - pjmlp 4y ago
        And yet they claim novelty while walking used trails...
    - colordrops 4y ago
      Most of the entire tech stack all the way down to transistors had for profit companies involved in their genisis and foundation.
      - pjmlp 4y ago
        Except the " Wasm is not the product of a for-profit company." seems to be unaware of it.
k__ 4y ago
I think, the main point is that it isn't owned by Oracle. But also, that it's more for non-GC languages.
diegocg 4y ago
Nothing. People have been able to compile other languages into java bytecode for decades already. That didn't turn java into the one true runtime to rule them all, and webassembly will not be any different. I wish browser makers would focus into making the browser user and development experience actually work instead of going after the latest shiny feature.
- PUSH_AX 4y ago
  > Nothing. How about not relying on the JRE? Mobile support? Partitioning between applet world and JS world?
  - kaba0 4y ago
    How are any of this relevant if we talk about a hypothetical future if Java was continued to be used in browsers? Browsers would include a JRE (which they actually did at a time as well, but that’s just a tiny technicality either way), there wasn’t even mobiles capable of browsing the net at the time, but there is nothing inherently unsolvable, it’s not like there is no partitioning between wasm and js world, but in this alternative reality there wouldn’t be js. Java could have access to the DOM.
- simonw 4y ago
  Being able to compile languages to Java bytecode doesn't help if you still have to convince users to install a Java runtime environment. WebAssembly doesn't have this problem: almost every user is already running a browser that supports it.
  - hashmash 4y ago
    In the early days of Java, it was bundled with the browser. But because Sun didn't make their own (popular) browser, they couldn't dictate the terms for what features a browser was expected to include.
vbezhenar 4y ago
wasm runs in your browser. Java does not.
- rjsw 4y ago
  Java could have been made to run well in a browser, giving applets good access to the DOM of their containing page wouldn't have been too difficult.
  - pjmlp 4y ago
    Not only it wasn't, it has always been possible to do so from Applets.
    - rjsw 4y ago
      When I wrote good access, I was really thinking that Java would have needed to provide an API at least as good as JQuery, not just a low-level way to walk nodes in a tree.
      - pjmlp 4y ago
        The API was there nevertheless.
- Jaxan 4y ago
  It used to, though.
- orev 4y ago
  They are using the past tense of Java. In case you don’t know, the primary use of Java when it came out was to run “applets” inside the browser. And it was terrible. It was later when it became mostly a server-side thing (which at the time was dominated by languages like Perl, PHP, etc.)
  - hawkeyedan 4y ago
    To be precise, applets were an early application of Java. But Sun Microsystems actually developed it in the long-standing dream of the “universal binary.” The project began in 1991 targeting set-top boxes. [source](https://web.archive.org/web/20100210225651/http://www.java.com/en/javahistory/ https://web.archive.org/web/20100210225651/http://www.java.c...) WASM is another iteration of the same noble idea done with different technologies at a different moment. Java and the JVM have been incredibly successful. WASM has the potential to bring the dream of a universal binary even farther.
nikki93 4y ago
You can compile C, C++ and a bunch of other languages to Wasm, while you can't do that with Java as a target. A lot of existing C code compiles unchanged. And Wasm also actually runs in all browsers nowadays without the user noticing a difference (eg. iOS Safari too).
- brian_herman 4y ago
  What we should be comparing it is to activeX and flash will it have the security that those two technologies didn't?
  - Georgelemental 4y ago
    WASM uses the browser sandbox, from what I understand it re-uses the same facilities that browsers use for JIT
    - ridiculous_fish 4y ago
      WASM's sandboxing as implemented in practice is different from JITs. It works by allocating a 4GB region of virtual memory and treating the base address as NULL. Pointers in WASM are 32 bit so they are unable to point outside the region. The big win is the runtime doesn't need to check pointers for validity. However there are some downsides relative to native code: 1. Can't address more than 4GB of memory 2. Can't be efficiently implemented on 32 bit systems 3. Can't share memory between WASM modules 4. NULL dereferences don't trap (I think) I would not be surprised if future CPUs had hardware support for this stuff, e.g. load/stores with a mask to confine the pointers.
      - pjmlp 4y ago
        Just like Solaris SPARC has been doing like for 10 years.
      - jb1991 4y ago
        Neat. I thought Web pages were limited to 2 GB memory. I guess tines have changed.
dragonwriter 4y ago
> What can wasm accomplish in that way that Java couldn't? I'm really confused about the hoopla. Provide relatively efficient support for languages other than JavaScript that is reliably available in major browsers without user action, an insecure plugin model, etc.
stevemk14ebr 4y ago
Java != JavaScript
hajile 4y ago
Wasm outright forbids things like GOTO and other potentially insecure features opting instead for structured programming. Java has been the subject of countless security vulnerabilities. Wasm also has the ability to stream bytecode and validate/compile as it streams (fast parsing was a major design goal) resulting in much faster startup times. Wasm is easier to integrate into the JIT/VM already shipping in browsers so they don't have to ship two massive engines. Wasm is a bit lower level which should result in faster execution than the JVM in the future. Wasm doesn't require garbage collection. Wasm has unsigned integers. Wasm isn't encumbered by Oracle.
- hashmash 4y ago
  Which Java vulnerabilities are you referring to which require breaking bytecode compatibility?
  - hajile 4y ago
    I misspoke (and updated my comment).
    - hashmash 4y ago
      Ok. I'm also curious about your comment regarding GOTO. How is it potentially insecure?
      - worik 4y ago
        > Ok. I'm also curious about your comment regarding GOTO. How is it potentially insecure? Really? Is that a question? The trend over the years has been to structure our code. GOTO throws all of that away. Jump straight over the guards.
        hashmash 4y ago
        The Java language doesn't have a goto statement, and so all code is properly structured. A labeled break statement is almost a goto statement, but it still obeys structuring rules -- i.e., you cannot jump into the middle of a loop. At the bytecode level, all structured constructs get compiled into forms that rely on goto statements. Is this inherently insecure? Should the bytecode require structured programming too? How does this guard against malicious use any more than verified bytecode that relies on gotos?
olalonde 4y ago
Become a web standard.
mikewarot 4y ago
It provides a security model that actually works. WASM code can't access the outside world, except for channels you explicitly provide to it. Everything before it eventually let you have full access to the host file system, if you asked nicely, were given permission, or leveraged a bug in the system.
- int_19h 4y ago
  wasm is only as secure as the runtime that you're using, and I would be extremely surprised if none of them have sandbox-breaking bugs in the long term.
  - Etherlord87 4y ago
    Can you elaborate? To my understanding you compile code into opcodes and it's as safe as the stack machine going through the opcodes. To my understanding the runtime is the part of the compiled code, and not the stack machine going through it.
- pjmlp 4y ago
  Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro https://www.youtube.com/watch?v=glL__xjviro "The Security Risk of Lacking Compiler Protection in WebAssembly" https://arxiv.org/abs/2111.01421 https://arxiv.org/abs/2111.01421
DonHopkins 4y ago
WebAssembly isn't owned by Oracle. That's the most important reason to use WebAssembly instead of Java. It's also nice that it can do all kinds of things Java can't, but that's just icing on the cake.
- bhaak 4y ago
  OP used "couldn't" and was referring IMHO to the days of Java applets.
johannes1234321 4y ago
On the browser side: What killed Java was to a large part loading times. First the Plugin had to load, then the bytecode had to be run. On many systems one immediately knew when Java was used by the browser getting slow and sleeping for a while. Flash loaded a lot faster (also systems were better, generally) however Flash apps completely messed with user experience. Nowadays JavaScript can do a lot of things better (say changing URL, history support, back button) which can be integrated with a wasm tool for having a way more seamless integration. As a user you simply don't notice if something is using JS or wasm. From there it imo carries over to the server side and other places. Java simply got a bad reputation as resource hog used for bad UI in Applets and many people looked elsewhere. And then wasm supports C and C++ (and more) with huge eco system of libraries, applications, ... (While of course these days a Java VM (incl. Android) is often used with non-Java languages as well)

What can wasm accomplish in that way that Java couldn't? I'm really confused about the hoopla.

pjmlp 4y ago

Some folks have need to create startups to fulfill a need we don't know we need to have solved.

bloppe 4y ago
Well, unlike Java, Wasm is not the product of a for-profit company. It's a W3C standard that actually does solve many problems most people didn't realize they had. It essentially obsoletes virtualization (CTO of Docker famously said "If WASM+WASI existed in 2008, we wouldn't have needed to created [sic] Docker. That's how important it is"). It will allow the creation of a unified software ecosystem across languages (Wasm "components" are designed to allow you to e.g. import numpy into a JavaScript project. See https://hacks.mozilla.org/2019/08/webassembly-interface-types/ https://hacks.mozilla.org/2019/08/webassembly-interface-type...). The virtual machine is designed from the ground up to make many types of vulnerabilities, such a stack smashing, impossible. And, as an open standard, it's not beholden to the whims and lawyers of Oracle. I'm not 100% certain the W3C working group won't end up fumbling it, but if you're not excited about wasm then you probably just don't know much about it.
- kaba0 4y ago
  Oracle was the company that completely open-sourced OpenJDK and even their own paid support JDK is just a minor modification of the former. Java and the JVM is also among the few languages/platforms with separate specifications, and multiple completely independent implementations. If anything, Java is a much much safer bet than the oligopoly of WebKit/Blink.
- pjmlp 4y ago
  Yet there are enough for profit companies on its genesis and foundation. As for Docker, it is basically Java Application Servers full with YAML spaghetti to the point it makes me miss Websphere 5. Or even better, mainframe and microcomputers language environments like on IBM i, z/OS and Unisys ClearPath. Maybe its founders should have learned what preceded it.
  - EUROCARE 4y ago
    The founders know very clearly what preceded it as they're working with the authors of these previous attempts (JVM, CLR, etc) to integrate their stacks with Wasm.
    - pjmlp 4y ago
      And yet they claim novelty while walking used trails...
  - colordrops 4y ago
    Most of the entire tech stack all the way down to transistors had for profit companies involved in their genisis and foundation.
    - pjmlp 4y ago
      Except the " Wasm is not the product of a for-profit company." seems to be unaware of it.

k__ 4y ago

I think, the main point is that it isn't owned by Oracle. But also, that it's more for non-GC languages.

diegocg 4y ago

Nothing. People have been able to compile other languages into java bytecode for decades already. That didn't turn java into the one true runtime to rule them all, and webassembly will not be any different. I wish browser makers would focus into making the browser user and development experience actually work instead of going after the latest shiny feature.

PUSH_AX 4y ago
> Nothing. How about not relying on the JRE? Mobile support? Partitioning between applet world and JS world?
- kaba0 4y ago
  How are any of this relevant if we talk about a hypothetical future if Java was continued to be used in browsers? Browsers would include a JRE (which they actually did at a time as well, but that’s just a tiny technicality either way), there wasn’t even mobiles capable of browsing the net at the time, but there is nothing inherently unsolvable, it’s not like there is no partitioning between wasm and js world, but in this alternative reality there wouldn’t be js. Java could have access to the DOM.
simonw 4y ago
Being able to compile languages to Java bytecode doesn't help if you still have to convince users to install a Java runtime environment. WebAssembly doesn't have this problem: almost every user is already running a browser that supports it.
- hashmash 4y ago
  In the early days of Java, it was bundled with the browser. But because Sun didn't make their own (popular) browser, they couldn't dictate the terms for what features a browser was expected to include.

vbezhenar 4y ago

wasm runs in your browser. Java does not.

rjsw 4y ago
Java could have been made to run well in a browser, giving applets good access to the DOM of their containing page wouldn't have been too difficult.
- pjmlp 4y ago
  Not only it wasn't, it has always been possible to do so from Applets.
  - rjsw 4y ago
    When I wrote good access, I was really thinking that Java would have needed to provide an API at least as good as JQuery, not just a low-level way to walk nodes in a tree.
    - pjmlp 4y ago
      The API was there nevertheless.
Jaxan 4y ago
It used to, though.
orev 4y ago
They are using the past tense of Java. In case you don’t know, the primary use of Java when it came out was to run “applets” inside the browser. And it was terrible. It was later when it became mostly a server-side thing (which at the time was dominated by languages like Perl, PHP, etc.)
- hawkeyedan 4y ago
  To be precise, applets were an early application of Java. But Sun Microsystems actually developed it in the long-standing dream of the “universal binary.” The project began in 1991 targeting set-top boxes. [source](https://web.archive.org/web/20100210225651/http://www.java.com/en/javahistory/ https://web.archive.org/web/20100210225651/http://www.java.c...) WASM is another iteration of the same noble idea done with different technologies at a different moment. Java and the JVM have been incredibly successful. WASM has the potential to bring the dream of a universal binary even farther.

nikki93 4y ago

You can compile C, C++ and a bunch of other languages to Wasm, while you can't do that with Java as a target. A lot of existing C code compiles unchanged. And Wasm also actually runs in all browsers nowadays without the user noticing a difference (eg. iOS Safari too).

brian_herman 4y ago
What we should be comparing it is to activeX and flash will it have the security that those two technologies didn't?
- Georgelemental 4y ago
  WASM uses the browser sandbox, from what I understand it re-uses the same facilities that browsers use for JIT
  - ridiculous_fish 4y ago
    WASM's sandboxing as implemented in practice is different from JITs. It works by allocating a 4GB region of virtual memory and treating the base address as NULL. Pointers in WASM are 32 bit so they are unable to point outside the region. The big win is the runtime doesn't need to check pointers for validity. However there are some downsides relative to native code: 1. Can't address more than 4GB of memory 2. Can't be efficiently implemented on 32 bit systems 3. Can't share memory between WASM modules 4. NULL dereferences don't trap (I think) I would not be surprised if future CPUs had hardware support for this stuff, e.g. load/stores with a mask to confine the pointers.
    - pjmlp 4y ago
      Just like Solaris SPARC has been doing like for 10 years.
    - jb1991 4y ago
      Neat. I thought Web pages were limited to 2 GB memory. I guess tines have changed.

dragonwriter 4y ago

> What can wasm accomplish in that way that Java couldn't? I'm really confused about the hoopla. Provide relatively efficient support for languages other than JavaScript that is reliably available in major browsers without user action, an insecure plugin model, etc.

stevemk14ebr 4y ago

Java != JavaScript

hajile 4y ago

Wasm outright forbids things like GOTO and other potentially insecure features opting instead for structured programming. Java has been the subject of countless security vulnerabilities. Wasm also has the ability to stream bytecode and validate/compile as it streams (fast parsing was a major design goal) resulting in much faster startup times. Wasm is easier to integrate into the JIT/VM already shipping in browsers so they don't have to ship two massive engines. Wasm is a bit lower level which should result in faster execution than the JVM in the future. Wasm doesn't require garbage collection. Wasm has unsigned integers. Wasm isn't encumbered by Oracle.

hashmash 4y ago
Which Java vulnerabilities are you referring to which require breaking bytecode compatibility?
- hajile 4y ago
  I misspoke (and updated my comment).
  - hashmash 4y ago
    Ok. I'm also curious about your comment regarding GOTO. How is it potentially insecure?
    - worik 4y ago
      > Ok. I'm also curious about your comment regarding GOTO. How is it potentially insecure? Really? Is that a question? The trend over the years has been to structure our code. GOTO throws all of that away. Jump straight over the guards.
      - hashmash 4y ago
        The Java language doesn't have a goto statement, and so all code is properly structured. A labeled break statement is almost a goto statement, but it still obeys structuring rules -- i.e., you cannot jump into the middle of a loop. At the bytecode level, all structured constructs get compiled into forms that rely on goto statements. Is this inherently insecure? Should the bytecode require structured programming too? How does this guard against malicious use any more than verified bytecode that relies on gotos?

olalonde 4y ago

Become a web standard.

mikewarot 4y ago

It provides a security model that actually works. WASM code can't access the outside world, except for channels you explicitly provide to it. Everything before it eventually let you have full access to the host file system, if you asked nicely, were given permission, or leveraged a bug in the system.

int_19h 4y ago
wasm is only as secure as the runtime that you're using, and I would be extremely surprised if none of them have sandbox-breaking bugs in the long term.
- Etherlord87 4y ago
  Can you elaborate? To my understanding you compile code into opcodes and it's as safe as the stack machine going through the opcodes. To my understanding the runtime is the part of the compiled code, and not the stack machine going through it.
pjmlp 4y ago
Usenix Security '20-Everything Old Is New Again: Binary Security of WebAssembly" https://www.youtube.com/watch?v=glL__xjviro https://www.youtube.com/watch?v=glL__xjviro "The Security Risk of Lacking Compiler Protection in WebAssembly" https://arxiv.org/abs/2111.01421 https://arxiv.org/abs/2111.01421

DonHopkins 4y ago

WebAssembly isn't owned by Oracle. That's the most important reason to use WebAssembly instead of Java. It's also nice that it can do all kinds of things Java can't, but that's just icing on the cake.

bhaak 4y ago
OP used "couldn't" and was referring IMHO to the days of Java applets.

johannes1234321 4y ago

On the browser side: What killed Java was to a large part loading times. First the Plugin had to load, then the bytecode had to be run. On many systems one immediately knew when Java was used by the browser getting slow and sleeping for a while. Flash loaded a lot faster (also systems were better, generally) however Flash apps completely messed with user experience. Nowadays JavaScript can do a lot of things better (say changing URL, history support, back button) which can be integrated with a wasm tool for having a way more seamless integration. As a user you simply don't notice if something is using JS or wasm. From there it imo carries over to the server side and other places. Java simply got a bad reputation as resource hog used for bad UI in Applets and many people looked elsewhere. And then wasm supports C and C++ (and more) with huge eco system of libraries, applications, ... (While of course these days a Java VM (incl. Android) is often used with non-Java languages as well)