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

TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

teavm.org

Post reply on HN
Print view View original

121–130 of 136 posts

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#121

Post by kodablah »

pjmlp wrote: post #107
sitkack wrote: post #49

Earlier quoted context omitted.

If only the JVM had included unsigned math.

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.

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#122

Post by konsoletyper »

dizon wrote: post #15
grzm wrote: post #14

Earlier quoted context omitted.

You don't need to have Java enabled in your browser.

The problem with that is you'll essentially re-download the entire JVM (and libraries) on each page load. If you don't want to use a Java applet, you would need to reimplement GC, JNI, and so on. Java didn't work on the web for a reason.

GC is only about 300 lines of code. There's no JNI in TeaVM (and never will be), instead of JNI there's JSO to interact with JavaScript, and still no interop layer for WebAssembly (that's why I claim WASM support to be experimental). JSO is rather lightweight, and I hope I'll be able to implement a lightweigh interop for WASM.

As for Java libraries, TeaVM is able to throw away unused parts of it, producing relatively small binaries.

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#123

Post by [deleted] »

doug1001 wrote: post #11
burke wrote: post #9

Earlier 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

[deleted]

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#124

Post by kodablah »

simfoo wrote: post #77

The argument against the critics saying WebAssembly would make the web less open was, that you could always disassemble WebAssembly and that said disassembly would be much more readable than for example x86 assembly. So - since a quick research did not turn up anything - is there a WASM to C "transpiler" that generates readable C?

> So - since a quick research did not turn up anything - is there a WASM to C "transpiler" that generates readable C?

I'm not aware of one, though it would probably be trivial to write. https://github.com/WebAssembly/binaryen has the helping code for things like parsing. Both https://github.com/kanaka/wac and https://github.com/WebAssembly/wasm-jit-prototype interpret WASM. The latter even JITs into LLVM IR.

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#125

Post by exabrial »

earenndil wrote: post #35
kodablah wrote: post #4

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 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.

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

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#126

Post by danjoc »

taxreform wrote: post #84

I read some parts of the spec of WebAssembly recently, and there were several things that disappointed me. To name a few: 1) There is no way to allocate in a function's variable stack continuous memory space that spans more than 8 bytes. This implies that if a function has as a local variable compound data structure such as an array or a struct, you have to a) have a global virtual stack pointer, b) manipulate the st…

What does this have to do with TeaVM? I see this as a generic tangent as it could be posted to any thread mentioning WebAssembly.

>Avoid unrelated controversies and generic tangents.

https://news.ycombinator.com/newsguidelines.html

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#127

Post by BatFastard »

MaxBarraclough wrote: post #99
amelius wrote: post #81

But how does garbage collection work? Is it of the stop-the-world kind?

Looks like simple mark-and-sweep, yes. https://github.com/konsoletyper/teavm/blob/d882fd1/core/src/...

So basically useless for browsers

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#128

Post by kodablah »

earenndil wrote: post #35
kodablah wrote: post #4

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 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.

> 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.

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#129

Post by pjmlp »

shakna wrote: post #113
pjmlp wrote: post #105

Earlier quoted context omitted.

So classical UNIX C compilers are now transpilers, because they always did text to text (C to Assembly), before forking to the assembler.

The first AIX C compiler called itself a "transcompiler" in it's manual, so yes, they are.

Any digitalized version of it available online?

Re: TeaVM – Ahead-of-time transpiler of Java bytecode to JavaScript or WebAssembly

#130

Post by burke »

lopatin wrote: post #62
burke wrote: post #9

Earlier 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.

There was a battle? Transpile is between human readable sources, and compiler is always into machine readable code. This is the only project that I've seen to (for some reason) not conform to that definition. I guess I don't see the point of contention.

> compiler is always into machine readable code

The frustrating bit is that this is absolutely not true. A compiler is anything that parses some text according to some grammar, manipulates it, and emits it in a different format. While the most well-known and popular compilers are for C, to emit machine code, there's nothing inherent in the definition of a compiler that means it can't emit something human-readable.

I wouldn't have nearly as much issue with this if the JavaScript community instead had decided "compiler isn't specific enough: we need different words for compilers that drop vs. maintain a level of abstraction", rather than "we need a word for a thing like a compiler, but that doesn't, as compilers apparently inherently do, drop a level of abstraction".

Post reply on HN