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

91–100 of 179 posts

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

#91

Post by brabel »

jasmer wrote: post #83
brabel wrote: post #75

Earlier quoted context omitted.

Why don't you just try? It seems to work fine: https://javafiddle.leaningtech.com/#JYWwDg9gTgLgBAKwIYDckDoB...

I did, as I said, those are likely 'Virtual WASM Direct Buffers' which are not really 'Direct (Memory) Buffers' - and therefore, not really what they are meant for, though it's impossible to tell. Given how WASM works, I'm pretty sure (but not certain) that anything that uses nio to interface to anything else is not going to work, other than maybe things which are 'fully contained'. The 'test' would be to dynamically…

So your complaint about a JVM environment in the browser is that it can't load DLLs from your Operating System?

Anyway, let's assume you're talking about a DLL or native lib it gets from the same origin. That also should work totally fine. Because CherpJ implements a virtual file system. I suspect even JNI will work fine. Anyway, doing stuff like that on a browser is way out of the norm, so it seems to me you're looking for a challenge and are not really interested in whether this can be used to run nearly every Java application out there, which it seems it can easily do.

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

#92

Post by adamfeldman »

nofunsir wrote: post #89
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?

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

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

#93

Post by yyyk »

spullara wrote: post #88
yyyk wrote: post #68

Earlier quoted context omitted.

>The other was headless and you had access to the DOM. Why no one built interesting applications with the latter is beyond me. Frameworks, HTML5 or even DHTML/AJAX didn't exist at the time. If you were already paying the cost of invoking Java/Flash/ActiveX, why would you access the DOM and pay extra rendering price - for an interface suited for documents, not applications?

You could have built DHTML/AJAX though just powered by Java code. SPAs could have been built then. Edit: Repliers live in an alternate reality where good applets were made and HTML didn't win.

The idiomatic and library-supported way to make a Java web application was to make a richer interface using Java itself. Why reinvent the wheel to make a HTML interface, only to incur a performance penalty?

EDIT: Java applets failed because of Java's poor integration and (at the time) performance and sandbox security. That had little to do with the DOM interface. Using that would have made things worse.

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

#94

Post by int_19h »

spullara wrote: post #88
yyyk wrote: post #68

Earlier quoted context omitted.

>The other was headless and you had access to the DOM. Why no one built interesting applications with the latter is beyond me. Frameworks, HTML5 or even DHTML/AJAX didn't exist at the time. If you were already paying the cost of invoking Java/Flash/ActiveX, why would you access the DOM and pay extra rendering price - for an interface suited for documents, not applications?

You could have built DHTML/AJAX though just powered by Java code. SPAs could have been built then. Edit: Repliers live in an alternate reality where good applets were made and HTML didn't win.

But, again, why would you do it in DHTML if you could do it in Swing, which was then (and arguably still is) better suited to apps?

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

#95

Post by gwbas1c »

knome wrote: post #87
gwbas1c wrote: post #77

Earlier quoted context omitted.

> In all seriousness, anything that spits out canvas for a simple textbox is completely misguided about what the web is. I suspect the goal is a way to bring Java desktop applications into the browser without rewriting the application from scratch. Personally, as a fan of Blazor, I thought this was going to be a Java-based analog of Blazor; or a modernized replacement for GWT. (One flavor of Blazor compiles C# to WAS…

>as a fan of Blazor I really dislike this stuff. It's easy-ish to write, but it's like the authors of it hate everything about the web. SPAs do a lot of annoying stuff, and blazor encourages all of it. I really hope things swing back away from this grotesque tight binding between the server and the client.

One of the nice things about SPAs is that they allow navigation without the latency needed to re-load all assets.

You can get there the old-fashioned way if all your assets are cached in the browser with long timeouts; but that implies that you're doing something like putting hashes in the asset URL and hashing them as part of your build process. (This, is why loading JavaScript and CSS from CDNs helps with performance.)

Otherwise, every time you navigate to a new page on a non-SPA, the browser still needs to send an IF-CHANGED-SINCE request to the server.

As a developer, though, the BIG drawback of SPAs is that they require building much stricter APIs for everything. In a traditional server-side HTML page, you can quickly prototype something where the code that's putting together the HTML has access to privileged data that you can't expose through an API. (IE, if you just need to prototype something, server-side HTML rendering code can directly talk to the database.)

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

#96

Post by int_19h »

lriel wrote: post #62
gordian-not wrote: post #60

Java in the browser? I am having a deja vu to gray background slow loading boxes

Yes, running bins in the browser. This is ActiveX all over again, but with java.

This is Java applets all over again, hence OP's reference to "gray boxes".

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

#97

Post by mike_hearn »

flohofwoe wrote: post #42
mike_hearn wrote: post #35

Earlier quoted context omitted.

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

I stand corrected. I thought the applet SM policy had forbidden JNI completely but forgot that code signing could turn it off.

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

#98

Post by PerditionC »

mwcampbell wrote: post #29

Is there any plan to implement accessibility, e.g. for screen reader users, in CheerpJ's implementation of Swing?

Last I checked (a year or so ago, but bug report not updated to indicate current release differs much) CheerpJ provides the full Java Accessibility API, however, from the bug report on this issue, the API calls are "not interpreted and converted by CheerpJ to corresponding browser functionalities". So from a practical standpoint currently lacks support, but have stated they may improve this in future. I haven't had the time to attempt it, but based on the API they expose [when I looked, may have changed since] to talk to the runtime from the browser, it looked feasible but not fun to wire up at least basic screen reader / automation support. From my experience with a Java application converted to running on its jvm, the performance is on par to running it previously hosted on Oracle jvm via Internet Explorer. It is good, except I hate I can't copy using ctrl-ins or shift-del because it requires ctrl-c pressed after initiating copy (presumably most people just press ctrl-c twice so minor inconvenience or maybe its a quirk of our installation).

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

#99

Post by mike_hearn »

pjmlp wrote: post #69
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.

Android folks are thinking about using WASM for NDK, with compilation to native code on the PlayStore. https://github.com/android/ndk/issues/1771

Apple already went down that road with bitcode and they abandoned it, or so I thought.

The problem is that you can't solve the problem of developers not adopting new hardware features by abstracting the hardware to a lowest common denominator, which is what WASM does and what it will always do (because the web guys have no interest in letting people write ARM or Intel only web pages, let alone NEON only web pages). You can see this problem in the writeup where the use case is posited to be SIMD, but that's only one of many possible features CPU vendors could add. What about all the others? Now instead of waiting for Android devs to adopt new features, you have to wait for WASM to get it and users to update their OS and Android devs to then adopt the new features as well. This doesn't sound faster.

So I'd guess that a better investment would be in better developer toolchains and emulators.

There are other problems with that approach:

1. How can devs measure performance if it's the Play Store that compiles the app? Upload it, download it and measure that? You never know what you're gonna get and the app may even be recompiled behind your back without you even doing a release.

2. An example of a painful transition was 32->64 bits, said to be hard due to the need for doubled up testing. Well, WASM doesn't fix that and it's not obvious how it could. It has a 32 and 64 bit variant and the need for testing both versions is driven by the way C/C++ work, not the way native code is expressed.

3. Even just abstracting SIMD isn't all that easy. The Java guys have spent years designing a SIMD abstraction that covers up the differences between AVX and NEON. C++ doesn't have any such abstraction, you literally code against intrinsics for the specific instructions. So it would only work if you assume a really awesome auto-vectorization compiler module, but the JVM guys also spent years trying that and eventually gave up. The JVM can auto-vectorize some things, but to exploit the full power of SIMD units automatically is too hard.

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

#100

Post by Alifatisk »

CyberDildonics wrote: post #80
Alifatisk wrote: post #56

This reminds me abit of java applets

I'm also getting serious java applet vibes from running java in the browser, which was exactly what java applets were.

Yeah, but this time, it doesn't have access to native parts like dll.
Post reply on HN