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

41–50 of 179 posts

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

#41

Post by kaba0 »

bheadmaster wrote: post #32
CJefferson wrote: post #24

Earlier quoted context omitted.

Do any of the native AOT implementations outperform the best JITs? I remember trying bcc’s Java compiler years ago, and it was significantly slower than standard JITted Java, but maybe better systems exist.

Considering the time-limit of JIT compilation, I'd say almost certainly yes. AOT can analyze code basically forever (ask C++ compilers), so there's a whole class of time-intensive optimizations that JIT simply cannot do. I'd personally always bet on AOT performance to beat JIT - to convince me otherwise is what I would require evidence for.

GraalVM native compiled binaries rarely beat out their JIT compiled counterparts - is that enough evidence?

The time spent optimizing is more than enough when you can focus the resources for the actually relevant parts.

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

#42

Post by flohofwoe »

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.

No, you could definitly call into native DLLs from a Java applet. Everything had to be code-signed, and at some point a permission popup was introduced, but it totally worked (that's how I "integrated" a Windows D3D game written in C++ into browsers ca 2010 until Chrome removed Java plugin support).

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

#43

Post by javier123454321 »

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.

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

#44

Post by garganzol »

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.

I think this is more for "write once, run anywhere side" of compiled Java. But we can achieve the same level of ubiquity with HTML nowadays.

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

#45

Post by garganzol »

kaba0 wrote: post #41
bheadmaster wrote: post #32

Earlier quoted context omitted.

Considering the time-limit of JIT compilation, I'd say almost certainly yes. AOT can analyze code basically forever (ask C++ compilers), so there's a whole class of time-intensive optimizations that JIT simply cannot do. I'd personally always bet on AOT performance to beat JIT - to convince me otherwise is what I would require evidence for.

GraalVM native compiled binaries rarely beat out their JIT compiled counterparts - is that enough evidence? The time spent optimizing is more than enough when you can focus the resources for the actually relevant parts.

Probably depends on what you are optimizing for. If this metric is an app startup time then AOT is super beneficial and always beats JIT without strings attached.

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

#46

Post by mtrycz2 »

jeroenhd wrote: post #34

With this and Ruffle, we will soon return to the days of Internet Explorer 6 but with 4k monitors! All we need now is to run ActiveX. I think BottledWine can run Windows executables in the browser, how hard would it be to simulate the ActiveX bindings?

Reminds me of "The fall and rise of JavaScript"

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

#47

Post by kaba0 »

garganzol wrote: post #45
kaba0 wrote: post #41

Earlier quoted context omitted.

GraalVM native compiled binaries rarely beat out their JIT compiled counterparts - is that enough evidence? The time spent optimizing is more than enough when you can focus the resources for the actually relevant parts.

Probably depends on what you are optimizing for. If this metric is an app startup time then AOT is super beneficial and always beats JIT without strings attached.

Well yeah, but that’s hardly a metric for performance.

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

#48

Post by giancarlostoro »

mike_hearn wrote: post #39
swsieber wrote: post #33

Earlier quoted context omitted.

> But the point of JNI is to provide language bindings. WASM doesn't automatically fix the need for those. True. I was imprecise. I'm fine with needing the language bindings / JNI. My main beef is with the platform specific native binaries that JNI binds too, and the complications (size or platform targeting) that they introduce to the build and distribution process.

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 binaries run on for each OS, and recipients would have to install it, or you hope the OS vendors adopt your standard. I would love to see such a project though.

Bonus points if it can be similar to DMG files where you drag it to your "Applications" folder to install, delete it to uninstall.

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

#49

Post by jasmer »

brabel wrote: post #40
jasmer wrote: post #27

Earlier quoted context omitted.

Yeah it's not really JVM. The thing with these kinds of ports is that they do some 'neat stuff' but ultimately, they don't come close to the real thing, often, not close enough to be a material substitute. The JVM is a very sophisticated and nuanced thing, 'duplicating it' and the standard libs is a very big deal. Theses are cool projects though and they have their use.

It is absolutely a real JVM. From the link: "CheerpJ is based on an unmodified OpenJDK environment, guaranteeing the same behavior on the browser compared to a native JVM. It includes many emulation layers to ensure Filesystem, Networking, Printing, Clipboard and many other subsystems work seamlessly." Did you actually manage to find anything that works in OpenJDK but not in CherpJ 3.0?

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

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

#50

Post by brabel »

jasmer wrote: post #49
brabel wrote: post #40

Earlier quoted context omitted.

It is absolutely a real JVM. From the link: "CheerpJ is based on an unmodified OpenJDK environment, guaranteeing the same behavior on the browser compared to a native JVM. It includes many emulation layers to ensure Filesystem, Networking, Printing, Clipboard and many other subsystems work seamlessly." Did you actually manage to find anything that works in OpenJDK but not in CherpJ 3.0?

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.
Post reply on HN