Live data from Hacker News

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

leaningtech.com

161–170 of 179 posts

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

#161
post #130

Earlier quoted context omitted.

> It's amazing how badly the Java ball got dropped. It still boggles my mind that Sun Microsystems fully owned the tech for the only ubiquitous browser plugin for full fledged applications with > 95% deployment and somehow screwed it up and went out of business a few years later. Despite all their engineering prowess it seems like they just couldn't make Java work seamlessly and smoothly. I'd like to think it was jus…

I graduated college around that time. Microsoft held an event on campus that took two hours, explaining how great it is to work at Microsoft. A month later Sun came to campus and spent two hours telling us how awful Microsoft is and we shouldn't have anything to do with them. What they didn't do was tell us why we should want to work for Sun. On a larger scale, Sun did seem to lose focus and concentrate too much on g…

Yeah, Sun stock really soared when they started going after Microsoft, but I kept pointing out that the valuation was from the distorted perception where they looked bigger because they were taking on a big foe. It was a sugar high that was obviously going to come crashing down if they weren't focused on delivering a better product.

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

#162

Can't wait to bring Spring, dependency injection and Factories into my browser apps!

Well I'd go with Swing and SB for the back end. Opens up the possibility of a monorepo though! Also that'd mean web and desktop code would be the same. That's awesome

Yes. I also just realized I can now use Hibernate to abstract all my db calls away in case I want to change db backend later. This is a life changing tech!

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

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

There were good applets made

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

#164
post #69

Earlier quoted context omitted.

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

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

Indeed, however it was mostly caused by relying on their own LLVM bitcode fork to achieve the stability that LLVM bitcode doesn't support, and eventually getting fed up of wasting development resources keeping it up to date with upstream.

As for WASM/NDK as replacement for JNI, I don't think it is a good idea, mostly due to how bad the overall NDK experience happens to be, and this won't make it better anyway.

Regarding 3, .NET does much better in this regard, with system numerics and processor specific intrisics.

Usually people tend to forget CLR was designed for C++ workloads as well, and it is reflected on its bytecodes.

WASM in general, I think its place is on the browser, anything else is just yet another take on bytecode deployments since the dawn of computing.

Maybe someone should write a P-Code to WASM compiler, to bring UCSD Pascal back into modern times, and make Pascal cool again.

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

#165

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?

Can't wait to play RuneScape in-browser again with Java applets!

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

#166
post #41

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.

Only if PGO data is part of the compilation input.

From GraalVM team themselves, https://youtu.be/sI-zXYLKzfk

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

#167
post #158

Earlier quoted context omitted.

Why is there a time limit? Doesn’t Java do multi tiered jitting with background compilation? Should be able to take as much time as needed in a background thread while code is executing in less optimized tier.

Java has 2 tiers, but even so it can’t take some unbounded amount of time doing every kind of analysis, as a big selling point of JIT compilers is optimizations based on assumptions, with some low chance of needing a de/reoptimization later. For what its worth, there is a vendor that uses LLVM as a JIT compiler (Falcon), but that really is not the bottleneck in most java applications.

OpenJDK has 2 tiers, other JVM implementations differ.

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

#169
post #134
post #122

Earlier quoted context omitted.

I think you’re a little misconceived, WebAssembly runs entirely in the client and have no bindings to the server, as far as the server is concerned such apps may as well be static HTML. This is Blazor WebAssembly. It will be just as trivial to run such on Mac, Linux or Windows server or any other plain web servers. TeaVM seems to be the same except it compiles Java to JavaScript which means has fast startup times. We…

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.

Blazor Server basically uses Web Sockets (with fallbacks) to communicate changes between client and server, this is far more efficient than using http request calls. State here is server side. But differs from all other frameworks in that state is trasmitted over sockets not http requests.

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

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

#170
post #119

Earlier quoted context omitted.

No, it's not going to load native libs, and 'jni' almost certainly does not work as normal, nio is widespread in java depends on 'native' buffers (actually native) and is a core part of Java. This is just one of a few examples of where 'this isn't really Java'. 'Most' apps will not run out of the box in this WASM config.

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