4 ms·

Can we all solemnly swear that we will never port the JRE to webassembly? Please? I mean, it's ridiculous to have Java Assembly -> WebAssembly -> CPU Assembly.

by rf15 9y ago

Can we all solemnly swear that we will never port the JRE to webassembly? Please? I mean, it's ridiculous to have Java Assembly -> WebAssembly -> CPU Assembly. Actually.... this is missing some more abstraction layers, like a precompiler or two - let's have Tomcat and Groovy or something on WebAssembly :D !

kodablah 9y ago
No [0], and no in the other direction [1] (disclaimer, I'm the author of the latter) 0 - https://github.com/konsoletyper/teavm https://github.com/konsoletyper/teavm 1 - https://github.com/cretz/asmble https://github.com/cretz/asmble
- rf15 9y ago
  I know. It just has so much potential to create awful endless abstraction stacks.
Matthias247 9y ago
I guess it's already too late. Last week there was this here: https://news.ycombinator.com/item?id=14587296 https://news.ycombinator.com/item?id=14587296 http://leaningtech.com/cheerpj/ http://leaningtech.com/cheerpj/ As far as I understand it currently uses JS as a target, but might switch to WASM soon. But don't worry about the abstraction layers, we might even have some more :-) E.g. some kind of intermediate language between WASM and CPU assembly (like LLVM IR). Or the CPU µops which are even below the real assembly. Or Java maven plugins like annotation processors, which transform some Java code into others. Or even on top of that some interface definition languages, which are transformed into Java through code generators.
vorg 9y ago
> let's have Tomcat and Groovy or something on WebAssembly :D ! Not sure if Apache Groovy is a good example of software that might benefit from a WebAssembly target. Somebody already tried creating an edition that compiles to Javascript, but I guess it doesn't get used much because its Wikipedia page is being considered for deletion on the grounds it's "Not a notable software library". [1] [1] https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Grooscript https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio...
- rf15 9y ago
  My entire joke is unnecessary layers of interpretation/abstraction that is either run live (THREE INTERPRETED BYTECODE STAGES!) or transpiled/compiled through. i.e. too much bullshit that is guaranteed to slow down your app significantly

by rf15 9y ago

kodablah 9y ago

No [0], and no in the other direction [1] (disclaimer, I'm the author of the latter) 0 - https://github.com/konsoletyper/teavm https://github.com/konsoletyper/teavm 1 - https://github.com/cretz/asmble https://github.com/cretz/asmble

rf15 9y ago
I know. It just has so much potential to create awful endless abstraction stacks.

Matthias247 9y ago

I guess it's already too late. Last week there was this here: https://news.ycombinator.com/item?id=14587296 https://news.ycombinator.com/item?id=14587296 http://leaningtech.com/cheerpj/ http://leaningtech.com/cheerpj/ As far as I understand it currently uses JS as a target, but might switch to WASM soon. But don't worry about the abstraction layers, we might even have some more :-) E.g. some kind of intermediate language between WASM and CPU assembly (like LLVM IR). Or the CPU µops which are even below the real assembly. Or Java maven plugins like annotation processors, which transform some Java code into others. Or even on top of that some interface definition languages, which are transformed into Java through code generators.

vorg 9y ago

> let's have Tomcat and Groovy or something on WebAssembly :D ! Not sure if Apache Groovy is a good example of software that might benefit from a WebAssembly target. Somebody already tried creating an edition that compiles to Javascript, but I guess it doesn't get used much because its Wikipedia page is being considered for deletion on the grounds it's "Not a notable software library". [1] [1] https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletion/Grooscript https://en.wikipedia.org/wiki/Wikipedia:Articles_for_deletio...

rf15 9y ago
My entire joke is unnecessary layers of interpretation/abstraction that is either run live (THREE INTERPRETED BYTECODE STAGES!) or transpiled/compiled through. i.e. too much bullshit that is guaranteed to slow down your app significantly