4 ms·

WebAssembly people continue to reinvent java, it seems

wyldfire 7y ago
I don't think Java bytecode was intended to be a portable representation targetable by any language. It was to be the representation for the Java language. Java applets have inferior sandboxing. [1] [1] https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...
- pjmlp 7y ago
  Follow my sibling comment for examples all the way back to 1958. JVM yes was initially designed for Java alone, but its research successor, GraalVM, does understand LLVM bitcode thanks to Sulong. As for "superior" WebAssembly sandboxing, it doesn't protect against internal corruption, due to lack of bounds checking on memory access. Which allows for injected scripts to try to coerce a loaded module to change its behavior. No need to escape the sandbox, sometimes changing the outputs is all that an attack requires. It remains to be seen how many WebAssembly CVEs will appear when it starts to be more widely targeted by black hats. And if those WASI modules happen to be written in languages like C and C++, I expect a couple of them to show up.
  - zeroimpl 7y ago
    If WebAssembly is running in the browser, it’s not calling into C/C++ modules. If WebAssembly isn’t running in the browser, it doesn’t need to be sandboxed. Thus I don’t think we need to be concerned over WASI sand boxing in the same way as applets.
    - pjmlp 7y ago
      If JavaScript is calling into WebAssembly modules compiled from C and C++, naturally do we have to care about security. The existing model does not prevent exploits taking advantage of internal memory corruption inside the sandbox.
pjmlp 7y ago
Not only Java UNCOL - https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/UNCOL IBM i ILE - https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/ilec/ilecmain.htm https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/... IBM z/OS Language Environment - https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zappldev/zappldev_88.htm https://www.ibm.com/support/knowledgecenter/zosbasics/com.ib... Xerox Mesa - http://www.softwarepreservation.org/projects/lang/mesa http://www.softwarepreservation.org/projects/lang/mesa Xerox Interlisp-D - http://www.softwarepreservation.org/projects/LISP/interlisp_family/#Interlisp-D_ http://www.softwarepreservation.org/projects/LISP/interlisp_... UCSD P-Code - https://en.wikipedia.org/wiki/P-code_machine https://en.wikipedia.org/wiki/P-code_machine Modula-2 M-Code - https://www.cfbsoftware.com/modula2/ https://www.cfbsoftware.com/modula2/ CLR - https://www.ecma-international.org/publications/standards/Ecma-335.htm https://www.ecma-international.org/publications/standards/Ec... PNaCL naturally - https://developer.chrome.com/native-client/reference/pnacl-bitcode-abi https://developer.chrome.com/native-client/reference/pnacl-b... And many many others that I didn't bother to refer to, just WebAssembly is cooler somehow.
- sanxiyn 7y ago
  Well, WebAssembly has a really nice formal semantics with a machine-checked proof of soundness. It is pretty cool.
- msla 7y ago
  And with all of that, it's utterly disqualifying for a systems language to have garbage collection. The fact it's been done means it's impossible to do. Well-known fact.
  - pjmlp 7y ago
    Xerox PARC, TI, MIT, ETHZ, Microsoft, Apple and Google beg to differ. In fact, Swift, Go, Java and .NET Native seem to be doing relatively well across their systems level projects, regardless on what naysayers think. Swift as C and Objective-C replacement on Apple platforms. Go as the implementation of gVisor used on ChromeOS Crostini security layer and Compute Cloud, Android GPGPU debugger, Fuchsia's TCP/IP stack. Java, alongside C++ for writing Project Trebel and Android Things drivers. Letting aside all those real time Java projects that run it bare metal, using the likes of PTC, Aicas and Gemalto compilers. .NET Native across Windows IoT Core and Azure Edge modules. But lets keep hating GC systems based languages instead.
dang 7y ago
"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html
jokoon 7y ago
Except java is proprietary, and requires a separate JVM, with all its GUI bloat and backward compatibility, while WASM was instantly implemented by all browsers and only does a very limited set of things, which is running an almost-binary in a browser. Any language can be compiled into WASM, but java being garbage collected, it's far from being the case. WASM is agnostic and flexible and allows a broad range of things. Java was never designed with the web in mind, and money ruined it, because it tried to do everything, but did everything poorly. WASM can actually make fast webapps a reality, maybe even on android. And even if it reinvents java, so what? At least it replaces it and fixes its many problems, they are many things that cannot be done in java. Its VM had no chance to be made standard in browsers... So in short, if you reinvents something, but you make it an open standard, it's clearly an improvement.
- pjmlp 7y ago
  Java is under GPL with Classpath exception.
  - iwillrunoutofsp 7y ago
    Since more than a decade after its initial release and well into the JavaScript revolution that made it obsolete in the browser.
    - pjmlp 7y ago
      Flash was what made Java obsolete on the browser, and both of them will take JavaScript crown thanks to WebAssembly + WebGL.

I don't think Java bytecode was intended to be a portable representation targetable by any language. It was to be the representation for the Java language. Java applets have inferior sandboxing. [1] [1] https://words.steveklabnik.com/is-webassembly-the-return-of-java-applets-flash https://words.steveklabnik.com/is-webassembly-the-return-of-...

pjmlp 7y ago
Follow my sibling comment for examples all the way back to 1958. JVM yes was initially designed for Java alone, but its research successor, GraalVM, does understand LLVM bitcode thanks to Sulong. As for "superior" WebAssembly sandboxing, it doesn't protect against internal corruption, due to lack of bounds checking on memory access. Which allows for injected scripts to try to coerce a loaded module to change its behavior. No need to escape the sandbox, sometimes changing the outputs is all that an attack requires. It remains to be seen how many WebAssembly CVEs will appear when it starts to be more widely targeted by black hats. And if those WASI modules happen to be written in languages like C and C++, I expect a couple of them to show up.
- zeroimpl 7y ago
  If WebAssembly is running in the browser, it’s not calling into C/C++ modules. If WebAssembly isn’t running in the browser, it doesn’t need to be sandboxed. Thus I don’t think we need to be concerned over WASI sand boxing in the same way as applets.
  - pjmlp 7y ago
    If JavaScript is calling into WebAssembly modules compiled from C and C++, naturally do we have to care about security. The existing model does not prevent exploits taking advantage of internal memory corruption inside the sandbox.

pjmlp 7y ago

Not only Java UNCOL - https://en.wikipedia.org/wiki/UNCOL https://en.wikipedia.org/wiki/UNCOL IBM i ILE - https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/ilec/ilecmain.htm https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_73/... IBM z/OS Language Environment - https://www.ibm.com/support/knowledgecenter/zosbasics/com.ibm.zos.zappldev/zappldev_88.htm https://www.ibm.com/support/knowledgecenter/zosbasics/com.ib... Xerox Mesa - http://www.softwarepreservation.org/projects/lang/mesa http://www.softwarepreservation.org/projects/lang/mesa Xerox Interlisp-D - http://www.softwarepreservation.org/projects/LISP/interlisp_family/#Interlisp-D_ http://www.softwarepreservation.org/projects/LISP/interlisp_... UCSD P-Code - https://en.wikipedia.org/wiki/P-code_machine https://en.wikipedia.org/wiki/P-code_machine Modula-2 M-Code - https://www.cfbsoftware.com/modula2/ https://www.cfbsoftware.com/modula2/ CLR - https://www.ecma-international.org/publications/standards/Ecma-335.htm https://www.ecma-international.org/publications/standards/Ec... PNaCL naturally - https://developer.chrome.com/native-client/reference/pnacl-bitcode-abi https://developer.chrome.com/native-client/reference/pnacl-b... And many many others that I didn't bother to refer to, just WebAssembly is cooler somehow.

sanxiyn 7y ago
Well, WebAssembly has a really nice formal semantics with a machine-checked proof of soundness. It is pretty cool.
msla 7y ago
And with all of that, it's utterly disqualifying for a systems language to have garbage collection. The fact it's been done means it's impossible to do. Well-known fact.
- pjmlp 7y ago
  Xerox PARC, TI, MIT, ETHZ, Microsoft, Apple and Google beg to differ. In fact, Swift, Go, Java and .NET Native seem to be doing relatively well across their systems level projects, regardless on what naysayers think. Swift as C and Objective-C replacement on Apple platforms. Go as the implementation of gVisor used on ChromeOS Crostini security layer and Compute Cloud, Android GPGPU debugger, Fuchsia's TCP/IP stack. Java, alongside C++ for writing Project Trebel and Android Things drivers. Letting aside all those real time Java projects that run it bare metal, using the likes of PTC, Aicas and Gemalto compilers. .NET Native across Windows IoT Core and Azure Edge modules. But lets keep hating GC systems based languages instead.

dang 7y ago

"Please don't post shallow dismissals, especially of other people's work. A good critical comment teaches us something." https://news.ycombinator.com/newsguidelines.html https://news.ycombinator.com/newsguidelines.html

jokoon 7y ago

Except java is proprietary, and requires a separate JVM, with all its GUI bloat and backward compatibility, while WASM was instantly implemented by all browsers and only does a very limited set of things, which is running an almost-binary in a browser. Any language can be compiled into WASM, but java being garbage collected, it's far from being the case. WASM is agnostic and flexible and allows a broad range of things. Java was never designed with the web in mind, and money ruined it, because it tried to do everything, but did everything poorly. WASM can actually make fast webapps a reality, maybe even on android. And even if it reinvents java, so what? At least it replaces it and fixes its many problems, they are many things that cannot be done in java. Its VM had no chance to be made standard in browsers... So in short, if you reinvents something, but you make it an open standard, it's clearly an improvement.

pjmlp 7y ago
Java is under GPL with Classpath exception.
- iwillrunoutofsp 7y ago
  Since more than a decade after its initial release and well into the JavaScript revolution that made it obsolete in the browser.
  - pjmlp 7y ago
    Flash was what made Java obsolete on the browser, and both of them will take JavaScript crown thanks to WebAssembly + WebGL.