[HN Gopher] CheerpJ 3.0: a JVM replacement in HTML5 and WASM to ...
___________________________________________________________________
CheerpJ 3.0: a JVM replacement in HTML5 and WASM to run Java on
modern browsers
Author : pjmlp
Score : 262 points
Date : 2023-05-09 12:48 UTC (10 hours ago)
(HTM) web link (leaningtech.com)
(TXT) w3m dump (leaningtech.com)
| hankman86 wrote:
| Who would want a lazily ported Java desktop UI in the browser?
|
| Web apps are bad enough as it is. But downloading massive jar
| files and execute them at a major performance penalty? No thanks.
| I will actively avoid websites that use heavyweight tech like
| this.
| Georgelemental wrote:
| 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.
| jvdvegt wrote:
| Is it though? Why did they rewrite it completely for Java 9
| and up, if it's just 'for legacy stuff'?
| riffic wrote:
| ugh no
| javier123454321 wrote:
| 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.
| meltedcapacitor wrote:
| That web is no more, sadly.
|
| It's just a question of time before the containerized crowd
| discover that the exact version of Chrome they test their
| website with can be compiled to the WASM+canvas platform,
| bundled with the website, and solve all browser issues
| forever...
| cbsmith wrote:
| >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...
|
| I get the joke. It is sad though how Java didn't end up being
| the ubiquitous runtime for browsers... It started off so
| promising... Compiling source to byte code is _really_ fast in
| Java (and modern browsers generally do much more work compiling
| JavaScript). Even if the browser downloaded source code (and
| why not? --byte code is so much more compact _and_ faster to
| parse), you wouldn 't even notice the compiling down to
| bytecode step.
|
| It's amazing how badly the Java ball got dropped.
| zmmmmm wrote:
| > 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 just a hard engineering challenge, but as
| someone who went all in on Java WebStart for deployment at
| one point and then watched them take it from a highly
| attractive platform to actively ruining it within a few
| years, I have to attribute it more to incompetence.
| garganzol wrote:
| 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.
| gwbas1c wrote:
| > 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 WASM, and uses a C#
| templating engine to generate HTML.)
| knome wrote:
| >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.
| gwbas1c wrote:
| 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.)
| ptx wrote:
| > _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
| [...] you 're doing something like putting hashes in the
| asset URL and hashing them as part of your build
| process._
|
| But that solves the problem, doesn't it? And it seems a
| lot simpler than implementing an SPA.
|
| Django has this feature built-in. You just have to enable
| ManifestStaticFilesStorage: https://docs.djangoproject.co
| m/en/4.2/ref/contrib/staticfile...
| gwbas1c wrote:
| > And it seems a lot simpler than implementing an SPA
|
| Depends on your design goals.
|
| BTW, I'm not pro/against SPAs. It's just a tool, and like
| all tools, they have their advantages and disadvantages.
|
| In general, the fact that you can update the page without
| a server-side round trip is a major advantage. Granted,
| you can also do that with server-side rendering; but then
| your rendering logic is defined in two places.
| dagaci wrote:
| 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.
|
| Web browsers and their fundamental development foundations
| are best described as a set of mostly well meaning
| compromises, and so even modern browsers have been updated
| to support all the other disagreeable things you have
| mentioned, even having the ability to navigate the browser
| history within an SPA
| TeaVMFan wrote:
| Agreed that many people will want to build true web single-
| page apps, not port Swing to the web in a Canvas.
|
| A Java option for modern web apps exists, and it's called
| Flavour: https://flavour.sourceforge.io/
|
| * Build SPAs in Java with HTML templates and components
|
| * Fast build times and batteries-included build framework
|
| * Easy calls to Java web services, just invoke a method and
| Flavour handles marshalling and unmarshalling, you just
| see/use Java objects.
|
| * Full-stack refactoring
|
| * Built on TeaVM, so you get the all the benefits of a
| mature, performant framework with support for threads and
| multiple JVM languages (bytecode-based transpilation).
|
| TeaVM vs Blazor comparison chart:
| https://frequal.com/java/TeaVmVsBlazorChart.html
|
| TeaVM longer comparison with Blazor:
| https://frequal.com/java/TeaVmVsBlazorWasm1-0.html
|
| Java Magazine article on Flavour and TeaVM:
| https://blogs.oracle.com/javamagazine/post/java-in-the-
| brows...
| gwbas1c wrote:
| > TeaVM vs Blazor comparison chart
|
| Blazor has the full task API. Asynchronous tasks run just
| like Javascript promises.
|
| Does TeaVM have true threading, or is it emulating threads
| via some higher-level concept? (IE, if I have a multicore
| CPU, will TeaVM take advantage of multiple cores?)
|
| Unless you're trying to do true CPU-intense parallel
| computing inside the browser, where you need the power of
| real CPU-level concurrency, "real threads" in the browser
| has no gain over the task API.
| shaftoe444 wrote:
| Java in the browser! There is nothing new under the sun.
| vlod wrote:
| I look forward to rewriting my app using Java applets. :)
| foobarbecue wrote:
| the Sun?
| znpy wrote:
| A man can dream
| trollied wrote:
| The parent comment was making a joke, based on Sol (our sun),
| and Sun Microsystems.
| foobarbecue wrote:
| you don't say
| tourgen wrote:
| [dead]
| mwcampbell wrote:
| Is there any plan to implement accessibility, e.g. for screen
| reader users, in CheerpJ's implementation of Swing?
| CyberDildonics wrote:
| Is there a single site using this and swing?
| mwcampbell wrote:
| CheerpJ is being sold as a commercial product, specifically
| for running the kind of line-of-business application that
| people need to be able to use to do their job. So it seems
| like a question worth asking.
| PerditionC wrote:
| 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).
| Traubenfuchs wrote:
| > multithreading
|
| ... but can it actually use multiple cores without limit, like
| the JVM itself?
|
| Is it a bug or a feature that I can not move the swing window
| despite it having a top-bar and closing X button?
| pulse7 wrote:
| RE Multithreading: just tried this: public
| class JavaFiddle { public static void main(String[]
| args) { new Thread(() -> System.out.println("Hello
| World from another thread!")).start();
| System.out.println("Hello World!"); } }
|
| on https://javafiddle.leaningtech.com/ and it works...
| lxgr wrote:
| Being able to execute Java threads does not imply that they
| are being mapped to actual OS-level threads (or any other
| concurrent construct).
|
| Back in the days of J2ME, some embedded JVMs emulated threads
| at the VM level, for example (due to the OS they were running
| on itself not supporting any threads, which was true for e.g.
| Palm OS and many non-smartphone OSes). This was called "green
| threads", as far as I remember.
| apignotti wrote:
| Window movement is implemented in the current production
| release (CheerpJ 2.x), but not yet as part of the CheerpJ 3.0
| rework.
| cmrdporcupine wrote:
| Neat
|
| Strikes me though that all these "managed-memory language VM
| inside a a WASM VM" projects for WASM keep having to build out
| garbage collection support (or run an existing GC inside WASM)
| for their runtimes. It's a bit of a stacking turtles problem, and
| seems wildly inefficient. I keep wondering how far off GC support
| for WASM runtimes is.
|
| In the meantime, while this is neat, I feel like it's a mis-use
| of what WASM is most suited for: cross-compiling C/C++ etc
| binaries to a "web" target. WASM as a container for multiple
| language _runtimes_ seems wildly inefficient.
| apignotti wrote:
| In the case of CheerpJ the virtual machine itself is pure C++
| compiled to WASM, but the JIT-ted code and the objects are pure
| JS. Garbage collection is natively handled by the browser.
|
| As WASM GC stabilizes we will consider supporting it as well.
| cmrdporcupine wrote:
| Ah, this is an interesting approach. Does JITing over to JS
| introduce problems with concurrency support though, given the
| lack of threads in the JS runtime?
| vmfunction wrote:
| JS does have thread.
|
| Worker on the client side:
|
| https://developer.mozilla.org/en-
| US/docs/Web/API/Web_Workers...
|
| Server-side/nodejs: https://nodejs.org/api/worker_threads.h
| tml#worker_threads_wo...
| jillesvangurp wrote:
| WASM Garbage collection is coming pretty soon. Currently, it's
| behind a feature flag in Chrome. I think the chrome flag for GC
| is due to be removed in a few months. I don't know when Firefox
| and Safari will roll out support. But I assume they won't be
| that far behind.
|
| One of the things I'm following that will use garbage
| collection support is the Kotlin wasm compiler which is
| currently available as an experimental option with kotlin 1.8
| and beyond. And of course with wasmer and wasmtime, it will
| also be possible to target edge computing with this eventually
| (as they roll out gc support in the next months). Fair warning,
| this stuff is very cutting edge currently. Wait six months or
| so for this to become more usable. The upcoming kotlin 2.0 is
| probably going to be seeing some usable early access version.
|
| There is already some experimental wasm support for Jetpack
| Compose multiplatform in the works as well. Currently you'd
| mostly use the kotlin-js compiler for that on the web but
| pretty soon you should be able to compile to wasm instead. This
| will work both with components that render to a canvas as html
| based web components. Advantages of kotlin wasm over kotlin-js:
| faster compilation and loading speeds. And having used kotlin-
| js, faster compilation speeds are very much welcome.
|
| If you are into multiplatform UI development, another thing
| that is interesting with this is the IOS support in compose. So
| with compose you should be able to target Android, IOS
| (native), Web (js and wasm) and desktop (jvm). Interesting new
| framework with not a lot of alternatives beyond react native
| and Flutter so far. And of course Kotlin is popular on Android
| and for cross IOS/Android development already. This stuff will
| take some time to mature but there was a lot of buzz around
| this topic at kotlin conf a few weeks ago. And of course with
| wasm and wasm components, you'd be able to do cross platform UI
| development and integrate the same components via wasm on each
| platform rather than having to engineer bespoke components for
| each platform.
| JohnFen wrote:
| Just in case those who prefer not to allow Java need this, here's
| some info about disabling WASM in various browsers.
|
| https://github.com/stevespringett/disable-webassembly
| whimsicalism wrote:
| I feel like the original primary reasons (security?) for doing
| so don't exist to the same degree for WASM-compiled Java.
| [deleted]
| flohofwoe wrote:
| 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.
| mike_hearn wrote:
| 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.
| whimsicalism wrote:
| wrong!
| flohofwoe wrote:
| 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).
| mike_hearn wrote:
| I stand corrected. I thought the applet SM policy had
| forbidden JNI completely but forgot that code signing
| could turn it off.
| [deleted]
| garbagecoder wrote:
| The day a website makes me download a nuApplet is the day I stop
| using the web.
| mannyv wrote:
| This is pretty awesome technically. Java everywhere without a JVM
| install. What's its footprint?
| jasmer wrote:
| 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.
| brabel wrote:
| 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?
| jasmer wrote:
| 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'.
| brabel wrote:
| 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.
| jasmer wrote:
| Direct ByteBuffers are used to interop with the
| underlying platform, particularly for the purpose of IO.
|
| I could be wrong, but I fail to see how 'WASM memory
| direct Buffers' will work in that scenario.
| lxgr wrote:
| What IO devices would you even have access to from a
| browser sandbox?
| brabel wrote:
| Why don't you just try?
|
| It seems to work fine:
|
| https://javafiddle.leaningtech.com/#JYWwDg9gTgLgBAKwIYDck
| DoB...
| jasmer wrote:
| 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
| load a lib/dll and see if the references are valid, which
| I doubt, firstly that'd imply that native dll/libs are
| possible, which I also doubt.
|
| These ports generally don't work 'as expected' the whole
| endeavour is about identifying the parts that work
| differently, and if/how to work around them or live
| within the constraints.
| brabel wrote:
| 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.
| jasmer wrote:
| 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.
| TeaVMFan wrote:
| A while back CheerpJ had a huge footprint and terrible startup
| time compared to TeaVM:
| https://renato.athaydes.com/posts/comparing-jvm-alternatives...
|
| TeaVM has become even smaller and faster since that article was
| published. The test suites are here in case someone wants to
| conduct a rematch: https://github.com/renatoathaydes/jvm-
| alternatives-to-js
| jeroenhd wrote:
| 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?
| mtrycz2 wrote:
| Reminds me of "The fall and rise of JavaScript"
| thesuperbigfrog wrote:
| Did you mean "The Birth and Death of Javascript":
|
| https://www.destroyallsoftware.com/talks/the-birth-and-
| death...
| bmacho wrote:
| Does anyone know a simple and portable flash and java player? A
| firefox 3 in a folder, or something like that. Or maybe a small
| linux in a virtual machine.
| doublepg23 wrote:
| If the goal is to play old Flash games Flashpoint is very
| good. https://bluemaxima.org/flashpoint/
| lxgr wrote:
| When everything else fails, you can just boot up a full Windows
| VM: https://copy.sh/v86/?profile=windows98
| signal11 wrote:
| If you run Windows and are jonesing for some ActiveX action,
| and want to be _really_ careful, you can run WSL, run LXDE on
| WSL, and run https://copy.sh/v86/?profile=windows98 on
| Firefox on LXDE[1].
|
| That's _maybe_ enough layers of indirection to make ActiveX
| safe :-)
|
| [1] https://imgur.com/a/VHYehLQ
| woodrowbarlow wrote:
| anyone remember dhtml, which allowed adding powerpoint-like
| transitions to hyperlinks?
| mikeryan wrote:
| DHTML was basically just a buzzword for the first SPA
| interactions.
|
| The first, real uses cases for XMLHttpRequests was sending
| chunks of HTML over the wire and updating the DOM via
| JavaScript - so "Dynamic HTML"
| baq wrote:
| See also htmx for a modern buzzword for this idea
| jahewson wrote:
| I had a book on DHTML in the late 90s long before ajax was
| a thing. It simply meant scripting the DOM. The MS version
| did have some fancy transition filters too.
| nofunsir wrote:
| THE SYSTEM. IS DOWN. THE SYSTEM. IS DOWN.
| doctor_eval wrote:
| Lightswitch rave!! But IIRC, The Cheat then gets sent to his
| room.
| adamfeldman wrote:
| 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
| jeroenhd wrote:
| Always a pleasant surprise to see how well Ruffle works with
| the HR website: https://homestarrunner.com/sbemails/45-techno
|
| The only thing I'm missing is the ability to find the easter
| eggs by hitting the tab key like you could do with Flash...
| spullara wrote:
| Amusingly, there were two different ways of running Java in the
| browser when it came out in the late 90s. One was Applet style
| where Java takes over a part of the canvas of the page and has to
| implement everything, like Flash or ActiveX. The other was
| headless and you had access to the DOM. Why no one built
| interesting applications with the latter is beyond me.
|
| https://docs.oracle.com/javase/tutorial/deployment/applet/ma...
|
| Now we are doing it all over again with WASM when it already
| existed and just wasn't used.
| yyyk wrote:
| >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?
| spullara wrote:
| 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.
| int_19h wrote:
| 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?
| regularfry wrote:
| Am I imagining it, or did someone do exactly that but with
| an invisible Flash component at one point?
| yyyk wrote:
| 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_.
| kaba0 wrote:
| Poor integration was also just politics, so nothing
| inherent in java
| garganzol wrote:
| I was hoping to see an AOT - but they say that currently it is
| just interpreter + JIT. This is beneficial for compatibility but
| counterproductive for speed. Nevertheless, an interesting
| project.
| CJefferson wrote:
| 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.
| bheadmaster wrote:
| 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.
| apignotti wrote:
| The tradeoffs are more subtle. A JIT compiler has more
| timing constraint, but more information about the runtime
| behavior of code.
|
| As a counter-point to your argument, consider a highly
| dynamic language such as JavaScript, in particular the '+'
| operator. An AOT compiler would have no choice but dispatch
| to a generic heavy implementation that could handle any
| possible combination of inputs. On the other hand a JIT
| compiler can observe the runtime values used and specialize
| using Inline Caches, potentially down to just a few
| instructions.
| kaba0 wrote:
| 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.
| garganzol wrote:
| 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.
| kaba0 wrote:
| Well yeah, but that's hardly a metric for performance.
| koito17 wrote:
| Why is this being downvoted? I find it pretty clear that
| there is a trade off between startup time and
| performance. You can also observe this sort of behavior
| by tweaking -XX:TieredStopAtLevel when launching Java.
| You get marginally faster startup times but at the cost
| of run-time performance. And anecdotally I've seen native
| images start up faster but also have marginally slower
| runtime performance than launching a JVM and letting C2
| do its thing.
| bheadmaster wrote:
| > is that enough evidence?
|
| It's _some_ evidence. Perhaps the HotSpot thing
| outperforms AOT on its own, it could be true.
|
| Somewhat equivalent to HotSpot but in AOT would be
| GraalVM's profile guided optimization. I believe that
| AOT+PGO should be much faster than JVM, but I don't have
| hard data.
| circuit10 wrote:
| There is TeaVM though which is AOT
|
| https://github.com/konsoletyper/teavm
| jsiepkes wrote:
| Google's J2CL (successor to GWT) is also AOT.
|
| https://github.com/google/j2cl
| sdeleuze wrote:
| J2CL sadly uses Java sources as the input, not JVM
| bytecode, which makes it hardly usable for a lot of use
| cases involving existing libraries.
| sdeleuze wrote:
| And Bytecoder which targets Wasm GC.
| https://github.com/mirkosertic/Bytecoder
| pulse7 wrote:
| In article they explain, that previous version (CheerpJ 2.0)
| used AOT, but "CI setup was often felt as an unwelcome burden,
| and many of enterprise users found it hard to run the actual
| AOT compiler binaries on their controlled environments". So
| they decided to go to interpreter + JIT instead of AOT...
| sepisoad wrote:
| good job, and kodus to you guys. BUT, it's sad to see that java
| (as a language not VM) still exists. It's such a bad language
| compared to many other existing options
| EdwardDiego wrote:
| DAE Java bad? Seriously.
| woooooo wrote:
| It still exists _because_ it 's "bad".
|
| Very small language initially, with some 1990s warts that we
| all understand, and new features are only added long after
| they've proved their worth elsewhere.
|
| This means a lot for long-term hiring and maintenance.
| lolive wrote:
| Take it easy. It was all just a troll !
| eklavya wrote:
| Could you elaborate on how it's bad compared to the
| alternatives?
| TeaVMFan wrote:
| Related, if you like Java but want to create a modern,
| Lighthouse-ready web app, check out Flavour:
|
| https://flavour.sourceforge.io/
| znpy wrote:
| What is Lighthouse in this context?
| tech234a wrote:
| The web benchmark created by Google?
| TeaVMFan wrote:
| The Lighthouse test tool in Chrome, commonly used to test
| real-world application performance.
|
| TeaVM apps score quite well on Lighthouse. Previous
| iterations of CheerpJ had challenges in startup time and
| download size. Results here:
| https://renato.athaydes.com/posts/comparing-jvm-
| alternatives...
|
| For a concrete test, try launching this full TeaVM/Flavour
| 5-letter word game, it downloads in <2s even on mobile.
| https://frequal.com/wordii/
| no_wizard wrote:
| For anyone interested in the Kotlin side of things:
|
| Kotlin has a great compat with Kotlin/JS[0]. they also have
| Compose For Web which is more WASM based[1] though its marked as
| experimental
|
| [0]: https://kotlinlang.org/docs/js-overview.html
|
| [1]: https://github.com/Kotlin/kotlin-wasm-
| examples/tree/main/com...
| WhereIsTheTruth wrote:
| kotlin is back on the menu! I love this language so much! I no
| longer use/need the JVM so i stopped using it, but with WASM
| comming, I might pick this language again
| esafak wrote:
| Have you used them in production and would you recommend it?
| ffactory wrote:
| The company I work for was a very early adopter of kotlin/js.
| During the pandemic we published an open source contact
| tracing web platform aimed at universities.
| https://github.com/studoverse/campus-qr The stack is actually
| great to work with. Having every property in React typed is
| nice and sharing classes between front and backend ensures
| you can't accidentally send the wrong fields or types.
| exabrial wrote:
| A 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.
| garganzol wrote:
| WASM runtime is so much better because it's a polyglot standard
| so close to a real CPU.
| Alifatisk wrote:
| This reminds me abit of java applets
| CyberDildonics wrote:
| I'm also getting serious java applet vibes from running java in
| the browser, which was exactly what java applets were.
| Alifatisk wrote:
| Yeah, but this time, it doesn't have access to native parts
| like dll.
| gordian-not wrote:
| Java in the browser? I am having a deja vu to gray background
| slow loading boxes
| lriel wrote:
| Yes, running bins in the browser. This is ActiveX all over
| again, but with java.
| int_19h wrote:
| This is _Java applets_ all over again, hence OP 's reference
| to "gray boxes".
| swsieber wrote:
| On the flip side, is there a JVM-based Wasm interpreter? JNI is
| great and all, but I love the thought of compiling native code to
| WASM to provide a single package for all plaform without extra
| redundant packages.
| mike_hearn wrote:
| Yes, and it will JIT compile the code to native if you're using
| GraalVM:
|
| https://github.com/oracle/graal/tree/master/wasm
|
| But the point of JNI is to provide language bindings. WASM
| doesn't automatically fix the need for those.
| swsieber wrote:
| > 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.
| pjmlp wrote:
| Android folks are thinking about using WASM for NDK, with
| compilation to native code on the PlayStore.
|
| https://github.com/android/ndk/issues/1771
| mike_hearn wrote:
| 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.
| mike_hearn wrote:
| 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 that WASM/WASI is
| basically a new OS which is incompatible with every other,
| so it requires ports.
|
| 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. Sort of
| like MachO fat binaries but more fine grained and not Apple
| specific.
|
| Graal also has some sort of capacity for that in the way it
| can execute LLVM bitcode. You can do it either inside a
| sandbox that looks like a virtualized Linux (syscalls are
| recompiled into upcalls into the JVM), or it can be allowed
| to access native code. There is a toolchain that you simply
| point your PATH at and it produces the necessary files.
| But, it's not well known, LLVM bitcode still requires JIT
| compilation before it can execute on the CPU, and the
| toolchain doesn't really cross-compile in the way I mean
| above. Plus bitcode isn't a stable format.
| giancarlostoro wrote:
| > 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.
| mike_hearn wrote:
| 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 fully utilize the
| CPU and OS, without excessive duplication (e.g. think
| about merging the text sections and symbol tables
| together but using something a bit like symbol versioning
| to keep the code for each OS separated).
| ledgerdev wrote:
| Maybe embed wasmtime? I'm familiar with
| https://github.com/bytecodealliance/wasmtime-dotnet but perhaps
| this for jvm? https://github.com/kawamuray/wasmtime-
| java/blob/master/examp...
|
| I too love the idea of embedding wasm modules to be used across
| platforms.
| frant-hartm wrote:
| Interpreter is slow, you need to run native. There is wasmer
| java, which is JNI binding to wasmer runtime.
|
| Then graal has wasm support, but you need graal, not just any
| JVM (you can also run in stock JVM, but only in interpreted
| mode with som graal libs, but this mode is not supported).
|
| And both of these are ok-ish for pure functions. If you need
| callbacks to your host (typically needed for plugins) you are
| screwed.
| kodablah wrote:
| I wrote https://github.com/cretz/asmble which has an AOT
| compiler and interpreter for WASM. Haven't worked on it for a
| while though.
| jasmer wrote:
| Graalvm targets WASM, 'work in progress'
| RyanHamilton wrote:
| For anyone looking for a free similar alternative (no swing), I
| can recommend doppio. I used doppio to provide an online version
| of the open source language interpreter I am building, you can
| try it here: https://www.timestored.com/jq/online/
|
| The main pain is that it's really really slow to load on firefox.
| brundolf wrote:
| Really impressive, and very exciting I'm sure for orgs with
| legacy applets that they can't afford to rewrite or get rid of
|
| Probably not intended for new greenfield projects
| dang wrote:
| Related ongoing thread:
|
| _Show HN: JavaFiddle - Compile, run and share Java code fully
| client side_ - https://news.ycombinator.com/item?id=35874969 -
| May 2023 (5 comments)
| juancn wrote:
| Quite interesting. I ran a single threaded micro benchmark
| (mostly memory bound) and it's roughly 5x slower than OpenJDK on
| the same hardware.
|
| Not bad at all.
___________________________________________________________________
(page generated 2023-05-09 23:00 UTC)