Mozilla announces WebAssembly System Interface, what JVM should have been

Also on client devices running on my credit card, factory management client screens and couple of car infotainment systems.

And on client devices across many corporations still safe from Electron madness.

Also, one thing less-known than that Java applets were in the popular Web browsers at one point (when JavaScript was said to be just a glue language to invoke the Java applet), was that Sun already had a richer, Java-centric Web browser, which used Java for content-type handlers. Imagine providing content as data of some type/format, and the browser would automatically download an appropriate UI for that type, on the fly, and integrate it into UI, and it would all be secure.

(I first saw Java when it was called Oak, and Sun had great people doing major things, Java only one of them. When Java applets first hit conventional Web browsers, most people thought they were for replacing animated GIFs, thanks to a demo program. I probably wrote some of the first Java desktop application code outside of Sun, partly to demonstrate that Java was a real applications development language. Well, the language was there, and in many ways a huge improvement over the C++ that most shrinkwrap and technical desktop application developers were moving to, though the library support took a while to catch up, and performance took longer.)

And as a whole (except for run in browser without plugin, which was never promised, AFAIR), they were all true or Java, relatively speaking, compared to what was available before.

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 analog instrument and there's generally wonder and curiosity. Show a computer science class a slide with a 1 MB hard drive compared to an 1TB SD card and there's generally ridicule and laughter. "Look how stupid they've been", not "we've learned many valuable lessons since".

Reinventing the wheel takes a lot of effort to be worth doing, because it takes a lot of effort to improve foundational technology, but it is sometimes worth doing if you are going to put an appropriate level of resources into it.

Null removal is completely compile-time anyway so it's complicated to compile but relatively simple to implement as a language upgrade at a certain version, and in this case it's also opt-in.

> Many Java language features are not supported by Java Card (in particular types char, double, float and long; the transient qualifier; enums; arrays of more than one dimension; finalization; object cloning; threads). Further, some common features of Java are not provided at runtime by many actual smart cards (in particular type int, which is the default type of a Java expression; and garbage collection of objects).

But yeah, even specification itself is WIP

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 the JVM. If you say it is, then it seems to be a failure in marketing of the JVM or something.

Since you seem to feel WASM is a waste, what are your thoughts on the failure of the JVM? Ie, why don't I have Go and Rust compile targets for the JVM, with JVM browser code running my JVM targets and etc?

If JVM truly does have all of these WASM-web oriented features then it is an impressive failure on JVMs part. Quite curious

I didn’t say iron fist, I said disproportionately affected.

1: https://www.merriam-webster.com/words-at-play/jive-jibe-gibe

Still doesn't compare to the Sun God and his silicon fist.

(With apologies to Steve Yegge.)

Haha, I'll defer to you then. But I'm still curious about this:

> you have to support arbitrary compiled code, with all the intentional or unintentional memory safety violations

But there are multiple barriers here, are there not? First, your code needs to be signed (and notarized, at some point), and then at runtime the app sandbox/entitlements/process separation ensures there's not much you can do even if you're running arbitrary code. Sure, the first "barrier" isn't necessarily all that restrictive or thorough, but the other one should ideally stop anything horrible?

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.

I'm not going to debate any points against the JVM, but all I know is that I can compile languages I want to all browsers today. Why can't I do that for the JVM?

Something must be a massive, gory failure of the JVM and/or the companies involved with the JVM for it to be an equal to that of WASM, and yet have zero traction for modern languages and browser targets.

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 language or the specific application. If you want to solve this in WASM, I predict you couldn't just compile all different languages to WASM anymore without significant changes to the codebases. If this would be feasible at all..

Rewriting those huge C/C++ codebases is simply not an option, new applications can be written in safe languages and then compiled to WASM.

At a very basic level it can be summed up with: the JVM approach to GLSL was to just throw it at the GPU, whereas the browsers worked on restricting WebGL to a super constrained subset (this was my fault, but is the correct thing to do :D )