Hacker News Reader

Comment by kodablah | Hacker News Reader

For the reverse, I wrote a WASM-to-JVM compiler: https://github.com/cretz/asmble.

I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI. But at this early stage, there's no common stdlib for all languages to share.

View on HN

> I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI

Uhhhhh. This sounds like a kind of silly thing to say, when you just described the jvm. Except for the part where there is a common stdlib.

If only the JVM had included unsigned math.

there is... 'char'; char is an unsigned 16bit primitive (of course, adding 2 chars results into an int and you need a cast but that's another story)

Legend goes Gosling did not found anyone at his department that could answer all his questions about unsigned arithmetic, hence why he left it out from Java's initial design.

However since Java 8, the java.lang numeric classes do support unsigned arithmetic.

Yes it is a bummer that byte is signed, requiring extra math to simulate unsigned.

Yup, I use those unsigned methods, e.g. https://github.com/cretz/asmble/blob/3cb439e887245f23bf876e8.... Luckily WASM only has 32/64 bit integer arithmetic.

I would have had a great answer: Normally I count upwards from 0.

> Except for the part where there is a common stdlib.

Yeah, and it's huge and interconnected (just see how much they had to do to get a java.base module and how large that still is). And the JVM has lots of specifics around threading, GC, OOP, classes, security model, etc. And many of those specifics don't translate to the needed safe-by-default, minimal-by-default bytecode for the web and other targets.

I could really go on for a long time about why applets failed and why JVM bytecode and the JVM runtime are terrible for the web (and any generic bytecode that doesn't target the web can't really be that generic). What is silly is ignoring all of this. Think about why there are already C++-to-WASM compilers after such a short time and no reasonably-usable and maintained C++-to-JVM compilers.

Whoever said JVM should be for the web? The question was, why don't we have a way to cross language boundaries and the answer was: we do, the jvm.

There is also a WASM to Java source transpiler: https://github.com/wrmsr/wava

> I think WASM has the ability for us to finally cross the language boundaries without marrying ourselves to C/C++ ABI

That is how many maninframes work, and the original idea behind the CLR.

Isn't the CLR just the same as the JVM?

No.

CLR was designed to be able to support multiple kinds of languages, including C and C++.

At the release event there were about 40 languages being supported by multiple vendors.

The SDK being offered across multiple developer magazines had samples for several languages.

CLR was born from Ext-VOS project, formelly known as COM Runtime, the idea being that Windows would eventually be fully .NET based.

The idea never came to be, because .NET belongs to DevTools and Windows team was never happy with it.

The biggest example being the sabotage during Longhorn development and how the Phoenix, Singularity and Midori projects were received by them.

Also CLR always had the option of AOT compilation.

Initially via NGEN, Bartok in Singularity later adopted in Windows 8 for store apps, Project N from Midori later .NET Native for UWP apps.

That's really interesting! How does calling WASM code on the JVM work?

And also in addition to a stdlib, maybe a great package management system. Is there a popular crate / maven / npm etc equivalent out there for wasm yet?

There seems to be a good deal of info in the README: https://github.com/cretz/asmble#compilation-details

I haven't dug deeply but it seems from the documentation that the project is trying to do things the 'right' way (mapping instructions to JVM bytecodes at a low level)... as opposed to, say, trying somehow to compile to Java code.

Reply on news.ycombinator.com