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

CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

leaningtech.com

Post reply on HN
Print view View original

51–60 of 179 posts

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#51

Post by frant-hartm »

swsieber wrote: post #15

On the flip side, is there a JVM-based Wasm interpreter? JNI is great and all, but I love the thought of compiling native code to WASM to provide a single package for all plaform without extra redundant packages.

Interpreter is slow, you need to run native. There is wasmer java, which is JNI binding to wasmer runtime.

Then graal has wasm support, but you need graal, not just any JVM (you can also run in stock JVM, but only in interpreted mode with som graal libs, but this mode is not supported).

And both of these are ok-ish for pure functions. If you need callbacks to your host (typically needed for plugins) you are screwed.

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#52

Post by jasmer »

brabel wrote: post #50
jasmer wrote: post #49

Earlier quoted context omitted.

Direct buffers? I mean, they're going to be 'virtual direct'? Or can I can't fathom how but I would imagine they're not going to be 'actually direct'.

WASM has memory, and any native code compiled to WASM will allocate on WASM memory. CheerpJ's runtime is written in C++, which when compiled to WASM knows how to allocate memory, so there's no reason why direct buffers won't work.

Direct ByteBuffers are used to interop with the underlying platform, particularly for the purpose of IO.

I could be wrong, but I fail to see how 'WASM memory direct Buffers' will work in that scenario.

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#53

Post by whimsicalism »

mike_hearn wrote: post #35
flohofwoe wrote: post #25

Earlier quoted context omitted.

Might be worth mentioning that Java applets could call into native DLLs (which was a major security risk), while there's no way to do the same from WASM.

They could only call into the JVM runtime, not arbitrary DLLs. WASM can do the same, that's how it talks to the browser. The difference is mostly the kernel sandboxing that browsers do.

wrong!

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#54

Post by mike_hearn »

giancarlostoro wrote: post #48
mike_hearn wrote: post #39

Earlier quoted context omitted.

I think what's needed here is actually just a cross-platform binary format that can be linked and loaded without using the OS native linker, along with an integration with cross-compilers. Java apps mostly use JNI to either access operating system specific APIs, or to access high performance hardware the JVM doesn't directly expose (like simd), and WASM doesn't help you with either. And then you also have the problem…

> On the other hand, if you had something like ELF, PE or Mach-O but designed for cross-platform distribution and which had a nice and convenient cross-building toolchain and a portable dynamic linker, then it'd be a lot easier to compile and distribute once but use on every OS. I mean... .NET VM and JVM kind of achieve this, but I think I get what you mean, you would either have to build the environment that these b…

I'm thinking of something a bit lower level than app packaging. But yeah think something like "jar for native code" but with the ability to directly dlopen() and dlsym() from it. So the file could contain native code that's OS or CPU specific and the dynamic linker (bundled with your app) would be able to successfully load the right one and get symbols from it. It'd just be a more convenient way to ship code that can fully utilize the CPU and OS, without excessive duplication (e.g. think about merging the text sections and symbol tables together but using something a bit like symbol versioning to keep the code for each OS separated).

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#57

Post by cbsmith »

javier123454321 wrote: post #43

If only we could get a new version of Java for the browser. Something more of a scripting language that is not compiled but interpreted. Could probably knock out a proof of concept in a week, might call it Javascript or something... In all seriousness, anything that spits out canvas for a simple textbox is completely misguided about what the web is.

>If only we could get a new version of Java for the browser. Something more of a scripting language that is not compiled but interpreted. Could probably knock out a proof of concept in a week, might call it Javascript or something...

I get the joke. It is sad though how Java didn't end up being the ubiquitous runtime for browsers... It started off so promising... Compiling source to byte code is really fast in Java (and modern browsers generally do much more work compiling JavaScript). Even if the browser downloaded source code (and why not? --byte code is so much more compact and faster to parse), you wouldn't even notice the compiling down to bytecode step.

It's amazing how badly the Java ball got dropped.

Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers

#59

Post by woooooo »

sepisoad wrote: post #55

good job, and kodus to you guys. BUT, it's sad to see that java (as a language not VM) still exists. It's such a bad language compared to many other existing options

It still exists because it's "bad".

Very small language initially, with some 1990s warts that we all understand, and new features are only added long after they've proved their worth elsewhere.

This means a lot for long-term hiring and maintenance.

Post reply on HN