Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Mozilla announces WebAssembly System Interface, what JVM should have been

theregister.co.uk

Post reply on HN
Print view View original

111–120 of 156 posts

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#111

Post by pjmlp »

avian wrote: post #58
ksec wrote: post #47

Earlier quoted context omitted.

>I really don't get why the community is hell bent on reinventing the wheel, especially when the main defense of npm is that you don't have to reinvent the wheel. It's really disheartening to see that the best minds of the generation are busy spending time to reinvent the same old things instead of trying to improve upon the existing systems. I think it might have to do with people considering 40 as very old in Silic…

I often wonder why this is the fact in software development and not nearly much so in other fields. Isn't the point of education that each generation doesn't have to learn past mistakes by repeating them? Do computer science curricula not include enough historical perspective? I feel like other fields of engineering don't have such a dismissive approach to their own pasts. Show an electrical engineering class an old…

In other fields of engineering no one would ever think of calling themselves engineer after a 6 months bootcamp training.

Sadly on several countries this is a thing, which also contributes to a low level of expectation, regarding the quality of delivered work.

My Informatics Engineering degree certainly did include historical perspective of previous languages, operating systems and hardware architectures.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#112

Post by asdkhadsj »

otabdeveloper1 wrote: post #98
asdkhadsj wrote: post #92

Earlier quoted context omitted.

> More or less. I mean, that used to be a thing you know. I did not know Java applets can be stream loaded (ie, optimized for the web). > WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems Not at all.. at least, not in my view. WASM is optimized for platform issues specific to the web. That is to say, how it behaves on load is the first priority. I never got that impression from…

> ...why don't I have Go and Rust compile targets for the JVM, with JVM browser code running my JVM targets and etc? The JVM is not a true VM. It's heavily coupled to the Java object model and the Java GC.

And yet so many posts here cry of history repeating itself and seem to imply we should just be using the JVM.

I'm honestly puzzled. Am I the one missing something? Why is the JVM crowd seemingly upset here?

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#113

Post by olliej »

jcranmer wrote: post #80
olliej wrote: post #22

Earlier quoted context omitted.

Yup, and work super aggressively to restrict it -- back when the JVM was supported, a large amount of the browser sandbox had to be extended to support the arbitrary behavior of the JVM, subsequently moving it out of process still required providing unrestricted access to OS components that you would rather they didn't. At a very basic level it can be summed up with: the JVM approach to GLSL was to just throw it at t…

By the time browsers were considering out-of-process plugins, the JVM was already thoroughly eclipsed by Flash. I think Flash's general brokenness (over half my browser crashes/hangs were caused by Flash) was the main motivation for out-of-process, not JVM's hugely broken sandbox.

Applets were eclipsed because of their monumentally expensive launch requirements - both time and memory.

The applets also made it hard to do a bunch of the simple games that were super popular - flash included a large amount of multimedia functions built in, and an editing environment that was geared towards interactive design.

The reason java took so long to move out of process was because the javabrowser bindings were unique to java, it did not use any of the normal plugin apis, and expected a lot of direct linkage to the host system.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#114

Post by that_jojo »

asdkhadsj wrote: post #92
that_jojo wrote: post #85

Earlier quoted context omitted.

> Are you saying that we could stick a JVM in the browser More or less. I mean, that used to be a thing you know. > the goal of WASM and the JVM were quite different WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems JVM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems

> More or less. I mean, that used to be a thing you know. I did not know Java applets can be stream loaded (ie, optimized for the web). > WASM: A universal write-once, run anywhere bytecode for heterogeneous networks of systems Not at all.. at least, not in my view. WASM is optimized for platform issues specific to the web. That is to say, how it behaves on load is the first priority. I never got that impression from…

I'm not anti-WASM. Actually, I think it's pretty cool.

And I have no particular JVM love. I use it exceedingly rarely.

It's just that you're being kind of a frustrated, pedantic tool right now.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#115

Post by ComputerGuru »

otabdeveloper1 wrote: post #99
kevingadd wrote: post #26

Earlier quoted context omitted.

In general the groups doing standardization for browser APIs and runtimes don't seem to care much about whether web applications are compromised, only whether the browser or host platform are compromised. It's reasonable for the latter two to be priorities, but when we're talking about huge gmail-tier applications running unsafe C in a sandbox that have access to All Your Important Data, we're going to massively regr…

> ...we're going to massively regret letting type safety and other features slide. PHP is memory safe, and yet is a larger source of data breaches and security bugs than C by (rough guess) an order of magnitude. C is not the bogeyman you're looking for.

PHP may be memory safe but the shitload of poorly written C extensions enabled by default on all hosts that shipped with the distribution from 1995 to 2010 sure as hell weren't.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#116

Post by pjmlp »

otabdeveloper1 wrote: post #103
btlr wrote: post #101

Earlier quoted context omitted.

Where did you get this "Java failed" idea? Java is one of the most widely used languages in the whole world...

Java failed as a portable language-agnostic VM for user-facing apps. You know, the use-case it was originally designed for. (I read the hype for Java 1.0, I was there.) Nobody at the time could imagine that Java would eventually become the enterprise COBOL replacement.

We develop on Windows, deploy across OS X, Windows, UNIX, mainframes and embedded devices, without re-compiling.

Looks pretty much living the dream of portable language-agnostic VM for user-facing apps to me.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#117

Post by pjmlp »

asdkhadsj wrote: post #76
manigandham wrote: post #28

I wonder what new standard we'll come up with 10-15 years from now that'll be titled "What WASM should have been".

Isn't that what the goal of software should be? Solving problems with older implementations? Do people think WASM is not better than the JVM for streaming browser based usage? Did it learn nothing from the JVM? The sarcasm in these threads always confuses me.

Yes, because WASM is basically politics due to the refusal of other browser vendors to adopt PNaCL, and it doesn't provide any security for memory bound and null pointer exploits inside the sandbox.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#118

Post by readittwice »

pjmlp wrote: post #67
readittwice wrote: post #64

Earlier quoted context omitted.

> WebAssembly is still not safe from internal memory corruption, due to lack of memory tagging and bounds checking. Unsafe applications won't ever be magically safe when compiling them to WebAssembly. Neither would this be the case when compiling to Java bytecode - if this was possible at all. IMHO WebAssembly is a compilation target and therefore not the right layer to solve this. This is the responsibility of the l…

Java bytecode requires bound checking and null pointer validation, as per the JVM specification. CLR proves the contrary, by having C++ support, with the difference between safe Assemblies (where typical memory corruption opcodes are not allowed, compilation via /CLR) and unsafe Assemblies, where WASM like opcodes are allowed. To load an unsafe Assembly, the host has to explicitly allow it. Similar examples on IBM an…

WASM has bounds checking on the linear memory as well.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#119

Post by pjmlp »

readittwice wrote: post #118
pjmlp wrote: post #67

Earlier quoted context omitted.

Java bytecode requires bound checking and null pointer validation, as per the JVM specification. CLR proves the contrary, by having C++ support, with the difference between safe Assemblies (where typical memory corruption opcodes are not allowed, compilation via /CLR) and unsafe Assemblies, where WASM like opcodes are allowed. To load an unsafe Assembly, the host has to explicitly allow it. Similar examples on IBM an…

WASM has bounds checking on the linear memory as well.

Care you point it where in the standard, because I don't see it on the memory access opcodes.

Re: Mozilla announces WebAssembly System Interface, what JVM should have been

#120

Post by readittwice »

pjmlp wrote: post #119
readittwice wrote: post #118

Earlier quoted context omitted.

WASM has bounds checking on the linear memory as well.

Care you point it where in the standard, because I don't see it on the memory access opcodes.

> A linear memory is a contiguous, mutable array of raw bytes. Such a memory is created with an initial size but can be grown dynamically. A program can load and store values from/to a linear memory at any byte address (including unaligned). Integer loads and stores can specify a storage size which is smaller than the size of the respective value type. A trap occurs if an access is not within the bounds of the current memory size.
Post reply on HN