I can only assume this means the inevitable end of Electron apps, now that running Eclipse is possible in the browser
CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
151–160 of 179 posts
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#152Earlier quoted context omitted.
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 look…
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.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#153I can only assume this means the inevitable end of Electron apps, now that running Eclipse is possible in the browser
"Eclipse on WASM - when electron and vscode just aren't slow enough"
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#154If 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.
Then we would have a horrible culture of polyfills and transpilers. We would have code that gets shipped unmiminized and with comments that weren’t removed. Eventually, that language will get repurposed for other tasks such as server-side applications or even mobile-applications (imagine shipping a separate runtime for extra language in mobile apps, ugh) due to the growth of the web and the rise in the number of web developers.
That sounds like a horrible idea. I hope it never comes to fruition.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#155Earlier quoted context omitted.
This lets you run an existing Java web applet that you already have, from way back when those were supported, in a modern browser with real sandboxing. Even if you don't have the original source. It's for legacy stuff, not new projects.
Is it though? Why did they rewrite it completely for Java 9 and up, if it's just 'for legacy stuff'?
Their AOT solution was clearly too complex for some potential clients, that seems like the real reason they rewrote it all, support for higher Java version is mostly a neat benefit (though Java 9 did still support Applet from my understanding, just deprecated).
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#156Using anything other than Javascript in the browser is absolute madness, and I'm a python dude. Learning the limitations, workarounds and build processes for using anything other than Javascript is going to take longer than just learning Javascript. I get it for moving large C++ applications onto the web, I get it for occasional fiddly bits and pieces like maybe a codec. But new web front end code in anything other t…
For whatever its worth, clojure.js is something I can accept - javascript was made as an attempt at a lisp with C-like syntax - using a hosted language which is a lisp only makes sense, especially that you can then share code with your backend.
And I am no lisp enthusiast, just find the abstraction very minimal there, plus good interop with the host language.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#157Earlier 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…
The new foreign function & memory interface is sort of like that, given a shared library that runs on multiple OSs you can use it as is with Java.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#158Earlier 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.
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.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#159A JVM in the browser wouldn't be so bad these days, since we have things like same-origin policies and sandboxing. Something like it could only run headless, had no AWT/Swing, and had an API to manipulate DOM and bindings to JS.
WASM runtime is so much better because it's a polyglot standard so close to a real CPU.
I believe truffle would’ve been a much better fit.
Re: CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on modern browsers
#160Earlier 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 recall those days. To be fair, it was asking a lot of the hardware at the time to run both a browser and Java itself. I also recall the JVM had painfully slow start times that weren't rectified for years. These were also largely the 1.x versions of the language to boot. On top of it all, Java integration was really just an excuse to plop a grossly out of place app UI in the browser window. Would have been much bett…
HotJava was pretty much proof that you could have Java well integrated into the browser. If you can do the browser entirely in Java and run applets smoothly, then there is no reason why a "better" browser runtime/implementation couldn't be even smoother.
The problem was that the browsers were busy loading up on every feature they could (including JavaScript) while also providing Java runtimes that would load after the fact (and the Java load times were often much better than the browser load times, but since the Java runtime load was deferred, it was a much more painful experience).
You could keep browsers lightweight by doing much of the stuff browsers were doing into Java, but the problem with that is that the browsers were in a race to differentiate from each other, and the whole point of Java was that the experience was uniform. So instead we got a rush of poorly considered browser capabilities that we were stuck with for an extremely long time.
I can't blame the browser makers... Sun never came up with a business proposition for them that encouraged focusing on a better Java experience.