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.
> 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.
TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
41–50 of 136 posts
Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
#42That word,"Transpile". Lol. GCC transpiles C to assembly.
Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
#43The last thing we need in hindsight to Meltdown and Spectre is running untrusted binaries in the browser aka WebAssembly. Btw deactivating WebAssembly support in Chrome 63 (up-to-date) doesn't work anymore!! chrome://flags/#enable-webassembly Setting it to "deactivated" does nothing, WebAssembly is still active.
I keep saying that WebAssembly is the revenge of Flash, Applets, Silverlight, ActiveX,... Just wait until it gets a bit more mature. It will be the same fun as when Ads moved away from Flash into HTML 5/JavaScript.
That said, it will lead to more closed commercial sites, but the JS outputted from webpack+babel+uglify is already unbelievably difficult to wade through without source maps. It's not significantly different imho.
Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
#44Earlier quoted context omitted.
> 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?
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.
Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
#45Earlier quoted context omitted.
I get that we've lost this battle, and some people seem to think there's a useful distinction being made, but man, does the word 'transpile' grate on me.
thank you; some consolation to know it's not just me does this seems like another instance of the annoying practice in our field of someone giving a name to a thing because they think it's new, though it's not (ie, source-to-source compilers have been around as long as source-to-bytecode compilers)--no need to re-name them wish they would just stop it and get the hell off my lawn
https://books.google.com/books?id=l5I_AQAAIAAJ&q="transpiler...
Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
#46The last thing we need in hindsight to Meltdown and Spectre is running untrusted binaries in the browser aka WebAssembly. Btw deactivating WebAssembly support in Chrome 63 (up-to-date) doesn't work anymore!! chrome://flags/#enable-webassembly Setting it to "deactivated" does nothing, WebAssembly is still active.
afaik, wasm is not 'binaries' in that it's not an arbitrary blob of machine code fed right into the cpu. it's still running in a sandbox (a la javascript) including similar limitations wrt CORS etc.
Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
#47Compile
I get that we've lost this battle, and some people seem to think there's a useful distinction being made, but man, does the word 'transpile' grate on me.
Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
#48Earlier quoted context omitted.
I get that we've lost this battle, and some people seem to think there's a useful distinction being made, but man, does the word 'transpile' grate on me.
well, there's even a wiki page for source-to-source translation. it's not always useful to distinguish 'truck' from 'automobile', but sometimes it is.
Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
#49For 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.
> 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.
Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly
#50Earlier quoted context omitted.
well, there's even a wiki page for source-to-source translation. it's not always useful to distinguish 'truck' from 'automobile', but sometimes it is.
It's sometimes useful to distinguish “truck” from “automobile”, but never when the thing being labelled a “truck” is a Honda Civic.