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

171–179 of 179 posts

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

#171

Post by jasmer »

pjmlp wrote: post #168
jasmer wrote: post #150

Earlier quoted context omitted.

What app is going to function without IO?

A CPU warmer. :)

Exactly. These 'ports' are more intellectually exciting than the are pragmatically useful, but they definitely can be useful, it's a matter of having the right product parameters around what they are good for and what not.

This is really an exercise in engineering thinking vs. product or 'solution oriented' thinking. You can usually tell where people's heads are at by how they react to these kinds of things.

Should note that 'people doing stuff because' is a core part of organic development, most things would not exist without that ethos floating around.

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

#172

Post by giancarlostoro »

mike_hearn wrote: post #54
giancarlostoro wrote: post #48

Earlier quoted context omitted.

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

Almost sounds like wine or similar then, but you only need to simulate what's not directly available.

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

#173

Post by lxgr »

jasmer wrote: post #171
pjmlp wrote: post #168

Earlier quoted context omitted.

A CPU warmer. :)

Exactly. These 'ports' are more intellectually exciting than the are pragmatically useful, but they definitely can be useful, it's a matter of having the right product parameters around what they are good for and what not. This is really an exercise in engineering thinking vs. product or 'solution oriented' thinking. You can usually tell where people's heads are at by how they react to these kinds of things. Should n…

Have you looked at the vendor’s website? This doesn’t strike me as a purely academic/intellectual "because we can" project at all.

And you still haven’t explained in any way why the lack of DirectBuffers or "IO" is a disqualifier for being able to run legacy applets in a modern browser without a JRE or other plugins.

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

#174

Post by jasmer »

lxgr wrote: post #173
jasmer wrote: post #171

Earlier quoted context omitted.

Exactly. These 'ports' are more intellectually exciting than the are pragmatically useful, but they definitely can be useful, it's a matter of having the right product parameters around what they are good for and what not. This is really an exercise in engineering thinking vs. product or 'solution oriented' thinking. You can usually tell where people's heads are at by how they react to these kinds of things. Should n…

Have you looked at the vendor’s website? This doesn’t strike me as a purely academic/intellectual "because we can" project at all. And you still haven’t explained in any way why the lack of DirectBuffers or "IO" is a disqualifier for being able to run legacy applets in a modern browser without a JRE or other plugins.

Just the opposite, the company has been around for 10 years and they have are an intellectually oriented professional services provider. This is quite common. The VM they built may or may not be a direct demand from a customer, my bet is it was an idea that someone had and they decided to make it, to see if there was some customer buy-in. There might be a niche need.

The problem with the 'A Customer Can Run An Applet In A Browser' as a solution, is because this won't materially work for most wide, public style deployments - there will be any number of snafus, and for more 'internal' style IT deployments, there are just easier, more robust ways to deploy a Java app.

I have explained how 'Direct Buffers' are a problem to anyone who understands what VM and Direct Buffers used for (they are inherently about bridging to native memory), which obviously is not going to be accessed in WASM context.

Actually - WASM itself is a great analogy for what is going on here. It's 'perennially almost there' tech aka a neat idea that has limited value in the real world, it's been around for so long and there isn't that much activity, or at least not commensurate with what it's supposed to be able to do. By the time WASM catches up, the performance of JS in V8 gets so much better it becomes 'good enough' which obviates the need for WASM. And so on it goes.

Something may eventually come from JVM in WASM, but what we see is a very early experiment.

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

#175

Post by knome »

dagaci wrote: post #169
knome wrote: post #134

Earlier quoted context omitted.

Ah, sure, for whatever WASM variant you're referring to. Whichever form of blazor I use pretty obviously makes calls back to the server to interact with client state on a per-event basis. If the backend has to restart, the clients all lose connection and die. I won't pretend to be an expert in the framework, or even C#. I had avoided both until recently, and this introduction hasn't made me particularly fond of eithe…

Its pretty fundamental stuff to know the difference between what is server side and what is client side. I think you will have a lot of trouble undertanding a framework without this. Blazor WebAssemly requires you make explicity Ajax-like Calls to external web services in order to interact with a server and data. There is no server side framework in WebAssembly for maintaining state. State is entirely client side. Bl…

At no point was I confused as to the server-side vs client-side nature of the software. I've been using what I assumed was the default of server-side blazor and was casually agreeing that, yes, a WASM compiled variant would obviously run fully in the browser.

>I'm not convinced you have actually used any kind blazor tbh

good for you, buddy.

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

#176

Post by nofunsir »

adamfeldman wrote: post #92
nofunsir wrote: post #89

Earlier quoted context omitted.

THE SYSTEM. IS DOWN. THE SYSTEM. IS DOWN.

Context: a classic episode from the Flash animation series Homestar Runner (and my favorite) https://www.youtube.com/watch?v=q1F4W8-DqjE . Original release date January 2003. Edit: the song is likely it https://youtu.be/JwZwkk7q25I

Twenty years ago?? Hmmm

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

#177

Post by pjmlp »

jasmer wrote: post #174
lxgr wrote: post #173

Earlier quoted context omitted.

Have you looked at the vendor’s website? This doesn’t strike me as a purely academic/intellectual "because we can" project at all. And you still haven’t explained in any way why the lack of DirectBuffers or "IO" is a disqualifier for being able to run legacy applets in a modern browser without a JRE or other plugins.

Just the opposite, the company has been around for 10 years and they have are an intellectually oriented professional services provider. This is quite common. The VM they built may or may not be a direct demand from a customer, my bet is it was an idea that someone had and they decided to make it, to see if there was some customer buy-in. There might be a niche need. The problem with the 'A Customer Can Run An Applet…

You are missing the part where everyone is busy re-inventing application servers in k8s/wasm.

That is where most money for WASM is now flowing.

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

#178

Post by saagarjha »

jasmer wrote: post #170
saagarjha wrote: post #152

Earlier quoted context omitted.

You still haven't explained how Java apps are going to know the difference here.

I've explained it well enough for anyone who understand how virtual machines and 'computers' work.

Clearly several people have no idea what you’re talking about, so either you’re bad at explaining or everyone around you is an idiot. I’ll let you decide which option you think is more likely.

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

#179

Post by lxgr »

jasmer wrote: post #174
lxgr wrote: post #173

Earlier quoted context omitted.

Have you looked at the vendor’s website? This doesn’t strike me as a purely academic/intellectual "because we can" project at all. And you still haven’t explained in any way why the lack of DirectBuffers or "IO" is a disqualifier for being able to run legacy applets in a modern browser without a JRE or other plugins.

Just the opposite, the company has been around for 10 years and they have are an intellectually oriented professional services provider. This is quite common. The VM they built may or may not be a direct demand from a customer, my bet is it was an idea that someone had and they decided to make it, to see if there was some customer buy-in. There might be a niche need. The problem with the 'A Customer Can Run An Applet…

> By the time WASM catches up, the performance of JS in V8 gets so much better it becomes 'good enough' which obviates the need for WASM.

One main benefit of WASM arguably isn't performance of newly developed applications, but the possibility to run arbitrary old applications (or new applications built on massive stacks of historically grown libraries) much more efficiently than emscripten alone allows.

> There might be a niche need.

Of course it's a niche need, Java applets haven't been mainstream for many years now! But as with any technology, a long tail exists.

> I have explained how 'Direct Buffers' are a problem to anyone who understands what VM and Direct Buffers used for (they are inherently about bridging to native memory), which obviously is not going to be accessed in WASM context.

I've only ever used Java on the server – are "Direct Buffers" commonly used by Java applets not bridging to JNI (which obviously won't run in a pure Java emulation/compatibility layer)?

Post reply on HN