6 ms·

Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with an

Indeed. The JVM did a lot of things right, however they missed three that are now solved with Wasm: * Completely tied to an ecosystem, and incompatible with another (you could not run C programs in the JVM) * Proprietary (vs based on an open standard) * They couldn't run in the browser seamlessly

pookeh 4y ago
There was a time when JVM ran in the browsers.
- syrusakbary 4y ago
  Yup, via Java Applets. But they were a pain to use, that's why I intentionally wrote "seamlessly" :P
  - ex3ndr 4y ago
    GWT allowed to run it without applets, also much more efficient than any current stack (since they dont support closure compiler)
    - switchbak 4y ago
      I spent years working with GWT, it's not nearly as simple as you describe. It's not running "Java" in the browser, it's compiling down (a subset of) Java to Javascript. That said, GWT was ahead of its time in a lot of ways, but it had warts galore.
  - freeone3000 4y ago
    They were better than Flash (which needed a weirder runtime, and couldn’t interact easily with the DOM, and didn’t have variables until version 3). This is hugely improved over JavaScript at the time (pre-XHR) and had less lock-in than ActiveX.
  - wwweston 4y ago
    As far as I could tell, the big pain point was performance -- they were just too slow on median machines during the late 90s/early 00s window they had mindshare. I actually enjoyed using them to get around a few browser limitations around the mid-to-late 00s, and they seemed feature/performance competitive with Flash unless what you were doing fit the media authoring model closely. But by then people were skeptical about Java and if you had to do anything to get it installed they wouldn't, and the direction was native web.
    - pjmlp 4y ago
      The Java Kernel project sorted that out.
- chunk_waffle 4y ago
  I recall around 2010 or so, when a company I worked for was creating a new, rather ambitions, web application. I had to argue against using Java Applets in favor of standard web technology for several components. Thankfully I won that battle. That web application is still in use, in production, today.
pitaj 4y ago
I would also mention that, especially in the past, the JVM sandboxing was not great. Which is why Applets were such a problem.
- KRAKRISMOTT 4y ago
  Not just in the past, arbitrary program sandboxing is not possible even today.
  - kllrnohj 4y ago
    Exactly, yet everyone pretends wasm is the exception for some reason...
    - nequo 4y ago
      I don't know about the limitations of sandboxing but I am curious. How does one break out of the JVM's or wasm's sandbox?
      - KRAKRISMOTT 4y ago
        I meant decent sandboxing on the JVM is not possible, that’s the advantage of WASM.
      - mike_hearn 4y ago
        The approach is the same in both cases - find an exposed API surface with a privileged implementation, find some way to confuse it, exploit. In a few cases there were JVM exploits that weren't based on that approach, almost always involving reflection or JIT compiler bugs. The people saying WASM is easier to sandbox than the JVM are sort of half right and half wrong. The hard part of sandboxing is exposing safe APIs to the sandboxed code. WASM solves that by simply not exposing any APIs at all. This essentially punts the sandbox construction to the user and will allow WASM vendors to claim a good security track record, which they will get by not doing very much. On the other hand, the OpenJDK guys are retreating from providing any sandbox at all and are taking it out of new Java versions. So you'll end up with mandatory exposed APIs that don't even try to be safe. Neither approach is really all that great if what you want is the ability to run a useful set of normal-ish programs in a safe way. GraalVM has its own sandboxing features which look like a decent compromise, and you can still use process or VM sandboxing on top.
ThePhysicist 4y ago
Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with the hope the ecosystem will standardize on it and give them opportunities to monetize that. So not that much unlike Java I'd say.
- deleted 4y ago
  [deleted]
- throwaway50609 4y ago
  Funny that you forgot about all the security issues of JVM applets that Wasm finally solved
  - baq 4y ago
    And now you can run a wasm jvm: https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ (there are others, too)
  - eyberg 4y ago
    Like this one? #include <stdio.h> #include <stdlib.h> int main() { char *s = "world"; s[0] = 'o'; s[1] = 'w'; s[2] = 'n'; s[3] = 'e'; s[4] = 'd'; printf("Hello, %s\n", s); }
    - throwaway50609 4y ago
      Just compiled and ran it on my system within Wasm, my computer is still fine. Your point? The point of Wasm is - programs can and will malfunction (and some will be malicious), so we have to protect the environment that runs it.
      - deleted 4y ago
        [deleted]
yazzku 4y ago
Memory usage too, right? A C++/Rust wasm won't consume a hundredth of the memory a JVM application typically uses. I like getting the job done on a 512MB RAM VPS. JVM the language might be cool; the bloat and forced-GC can be spared.
- icedchai 4y ago
  JVM ran in relatively little memory back in the day. I remember running applets on ~16 megabyte systems. Compare that to today where you need a half gig of RAM to even launch a browser.
  - mhitza 4y ago
    Right, the internet caffee computers I used to hang out at in the early 2000's had around the 128-256mb of RAM memory, and Java/Flash used to run just fine. Although Java Applets usually seemed to take longer to download, and used to wait a lot of time to start the JVM after that.
- pjmlp 4y ago
  Just like a JVM for embedded development won't.
- jeroenhd 4y ago
  Java can be fast and memory efficient. The problem I see with many Java programs is that they're built on top of layers upon layers of frameworks. Web server frameworks on top of multithreading frameworks with database ORM frameworks and microservice frameworks all calling in and out of each other. Stack traces that end up accumulating 30 or 40 calls before actual product code even begins. Tuning the garbage collector often helps, modern Java has excellent GC options that will make most software just run better. That's often not an option when you're stuck with JRE 8 because of the curse of legacy code, but modern JREs have made significant progress in both memory management and general performance optimizations. Port the same abstractions to any language and you'll get very similar performance issues. I've seen plenty of NodeJS applications crash because they grew out of the 2GiB memory limit I set up, and those node processes weren't doing anything that I deemed worth more than half a gigabyte of RAM either. The JVM is somewhat aggressive in claiming RAM as memory usage grows, but that often leads to a performance increase in the comparisons I've done. Setting parameters (-xmx / -xms) can often reduce the amount of memory used significantly at the cost of slower application startups.
michaelmior 4y ago
> you could not run C programs in the JVM Not entirely true, but of course there has never been any official support. http://nestedvm.ibex.org/ http://nestedvm.ibex.org/
deleted 4y ago
[deleted]
tubs 4y ago
You can't run c in wasm. You can compile c to wasm and run that. In the same way one could compile c to java byte code, write a wrapper program to allocate the "heap", disable the gc and execute it in close to the same way it executes in a wasm runtime.
0xbadcafebee 4y ago
I'm still flabbergasted that all these people, in the year 2023, think a hypertext markup document viewer with a terrible UX and bizarre design restrictions that takes 4GB of RAM to run and re-implements the features of an entire operating system is the end-all be-all of technology. If it doesn't run in a web browser it's worthless. I can't even come up with a metaphor for it. We're choosing to be stuck with shitty antiquated technology because it's easier than making something better. It's depressing. Like a world that never got past the horse and buggy. Large engines powered by steam would require additional investment in refining of steel and making giant cast or forged parts... easier to just stick with the horse.
- reginaldo 4y ago
  The browser "won" on seamless distribution. The browser is all the things you said and worse. It conflates the developer API (which could be as complex as the collective human comprehension will allow) with the execution environment (which must be as simple as possible and understandable to mostly anyone). I have a dream that the browser will turn inside out and start losing APIs that will be reimplemented on WebAssembly. But WebAssembly is moving too slowly e.g. with regards to tail calls and parallelism. So it's probably just a dream from now[1]. [1] https://www.youtube.com/watch?v=zlQEQQSqZ9g https://www.youtube.com/watch?v=zlQEQQSqZ9g -> it's an old dream that others have had before.
- MR4D 4y ago
  Unfortunately, the world is scheduled to end (or reboot if you prefer) at 03:14:07 UTC on January 19th, 2038. [0] So, that means that the remake of an OS that we call a browser is likely to be the pinnacle of computing for our lifetimes. Hopefully after the Great Reboot of 2038, the next generation will learn from our computing mistakes, but since we've never learned from those that came before us, it's highly unlikely. But at least they will have to start from scratch, so there's a chance! [0] - https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
- mch82 4y ago
  > Like a world that never got past the horse and buggy At lunch one day a colleague explained that the size of the space shuttle could be linked to the width of two horses walking on a Roman road :-) One of my favorite lunch breaks of all time.
mdellavo 4y ago
It's not an open standard but the JVM spec is publically available and intended for multiple implementations https://docs.oracle.com/javase/specs/jvms/se8/html/ https://docs.oracle.com/javase/specs/jvms/se8/html/

pookeh 4y ago

There was a time when JVM ran in the browsers.

syrusakbary 4y ago
Yup, via Java Applets. But they were a pain to use, that's why I intentionally wrote "seamlessly" :P
- ex3ndr 4y ago
  GWT allowed to run it without applets, also much more efficient than any current stack (since they dont support closure compiler)
  - switchbak 4y ago
    I spent years working with GWT, it's not nearly as simple as you describe. It's not running "Java" in the browser, it's compiling down (a subset of) Java to Javascript. That said, GWT was ahead of its time in a lot of ways, but it had warts galore.
- freeone3000 4y ago
  They were better than Flash (which needed a weirder runtime, and couldn’t interact easily with the DOM, and didn’t have variables until version 3). This is hugely improved over JavaScript at the time (pre-XHR) and had less lock-in than ActiveX.
- wwweston 4y ago
  As far as I could tell, the big pain point was performance -- they were just too slow on median machines during the late 90s/early 00s window they had mindshare. I actually enjoyed using them to get around a few browser limitations around the mid-to-late 00s, and they seemed feature/performance competitive with Flash unless what you were doing fit the media authoring model closely. But by then people were skeptical about Java and if you had to do anything to get it installed they wouldn't, and the direction was native web.
  - pjmlp 4y ago
    The Java Kernel project sorted that out.
chunk_waffle 4y ago
I recall around 2010 or so, when a company I worked for was creating a new, rather ambitions, web application. I had to argue against using Java Applets in favor of standard web technology for several components. Thankfully I won that battle. That web application is still in use, in production, today.

pitaj 4y ago

I would also mention that, especially in the past, the JVM sandboxing was not great. Which is why Applets were such a problem.

KRAKRISMOTT 4y ago
Not just in the past, arbitrary program sandboxing is not possible even today.
- kllrnohj 4y ago
  Exactly, yet everyone pretends wasm is the exception for some reason...
  - nequo 4y ago
    I don't know about the limitations of sandboxing but I am curious. How does one break out of the JVM's or wasm's sandbox?
    - KRAKRISMOTT 4y ago
      I meant decent sandboxing on the JVM is not possible, that’s the advantage of WASM.
    - mike_hearn 4y ago
      The approach is the same in both cases - find an exposed API surface with a privileged implementation, find some way to confuse it, exploit. In a few cases there were JVM exploits that weren't based on that approach, almost always involving reflection or JIT compiler bugs. The people saying WASM is easier to sandbox than the JVM are sort of half right and half wrong. The hard part of sandboxing is exposing safe APIs to the sandboxed code. WASM solves that by simply not exposing any APIs at all. This essentially punts the sandbox construction to the user and will allow WASM vendors to claim a good security track record, which they will get by not doing very much. On the other hand, the OpenJDK guys are retreating from providing any sandbox at all and are taking it out of new Java versions. So you'll end up with mandatory exposed APIs that don't even try to be safe. Neither approach is really all that great if what you want is the ability to run a useful set of normal-ish programs in a safe way. GraalVM has its own sandboxing features which look like a decent compromise, and you can still use process or VM sandboxing on top.

ThePhysicist 4y ago

Funny that most people seem to have forgotten that browsers used to ship with Java support. Not saying that was a good thing, but 20 years ago you could run JVM apps in the browser without issues. Also, there are dozens of language runtimes for the JVM, e.g. Ruby, Python, Golang, Javascript, Scheme, .... And regarding proprietary software, Wasmer is a for-profit startup that seems to offer open-source tooling with the hope the ecosystem will standardize on it and give them opportunities to monetize that. So not that much unlike Java I'd say.

deleted 4y ago
[deleted]
throwaway50609 4y ago
Funny that you forgot about all the security issues of JVM applets that Wasm finally solved
- baq 4y ago
  And now you can run a wasm jvm: https://leaningtech.com/cheerpj/ https://leaningtech.com/cheerpj/ (there are others, too)
- eyberg 4y ago
  Like this one? #include <stdio.h> #include <stdlib.h> int main() { char *s = "world"; s[0] = 'o'; s[1] = 'w'; s[2] = 'n'; s[3] = 'e'; s[4] = 'd'; printf("Hello, %s\n", s); }
  - throwaway50609 4y ago
    Just compiled and ran it on my system within Wasm, my computer is still fine. Your point? The point of Wasm is - programs can and will malfunction (and some will be malicious), so we have to protect the environment that runs it.
    - deleted 4y ago
      [deleted]

yazzku 4y ago

Memory usage too, right? A C++/Rust wasm won't consume a hundredth of the memory a JVM application typically uses. I like getting the job done on a 512MB RAM VPS. JVM the language might be cool; the bloat and forced-GC can be spared.

icedchai 4y ago
JVM ran in relatively little memory back in the day. I remember running applets on ~16 megabyte systems. Compare that to today where you need a half gig of RAM to even launch a browser.
- mhitza 4y ago
  Right, the internet caffee computers I used to hang out at in the early 2000's had around the 128-256mb of RAM memory, and Java/Flash used to run just fine. Although Java Applets usually seemed to take longer to download, and used to wait a lot of time to start the JVM after that.
pjmlp 4y ago
Just like a JVM for embedded development won't.
jeroenhd 4y ago
Java can be fast and memory efficient. The problem I see with many Java programs is that they're built on top of layers upon layers of frameworks. Web server frameworks on top of multithreading frameworks with database ORM frameworks and microservice frameworks all calling in and out of each other. Stack traces that end up accumulating 30 or 40 calls before actual product code even begins. Tuning the garbage collector often helps, modern Java has excellent GC options that will make most software just run better. That's often not an option when you're stuck with JRE 8 because of the curse of legacy code, but modern JREs have made significant progress in both memory management and general performance optimizations. Port the same abstractions to any language and you'll get very similar performance issues. I've seen plenty of NodeJS applications crash because they grew out of the 2GiB memory limit I set up, and those node processes weren't doing anything that I deemed worth more than half a gigabyte of RAM either. The JVM is somewhat aggressive in claiming RAM as memory usage grows, but that often leads to a performance increase in the comparisons I've done. Setting parameters (-xmx / -xms) can often reduce the amount of memory used significantly at the cost of slower application startups.

michaelmior 4y ago

> you could not run C programs in the JVM Not entirely true, but of course there has never been any official support. http://nestedvm.ibex.org/ http://nestedvm.ibex.org/

deleted 4y ago

[deleted]

tubs 4y ago

You can't run c in wasm. You can compile c to wasm and run that. In the same way one could compile c to java byte code, write a wrapper program to allocate the "heap", disable the gc and execute it in close to the same way it executes in a wasm runtime.

0xbadcafebee 4y ago

I'm still flabbergasted that all these people, in the year 2023, think a hypertext markup document viewer with a terrible UX and bizarre design restrictions that takes 4GB of RAM to run and re-implements the features of an entire operating system is the end-all be-all of technology. If it doesn't run in a web browser it's worthless. I can't even come up with a metaphor for it. We're choosing to be stuck with shitty antiquated technology because it's easier than making something better. It's depressing. Like a world that never got past the horse and buggy. Large engines powered by steam would require additional investment in refining of steel and making giant cast or forged parts... easier to just stick with the horse.

reginaldo 4y ago
The browser "won" on seamless distribution. The browser is all the things you said and worse. It conflates the developer API (which could be as complex as the collective human comprehension will allow) with the execution environment (which must be as simple as possible and understandable to mostly anyone). I have a dream that the browser will turn inside out and start losing APIs that will be reimplemented on WebAssembly. But WebAssembly is moving too slowly e.g. with regards to tail calls and parallelism. So it's probably just a dream from now[1]. [1] https://www.youtube.com/watch?v=zlQEQQSqZ9g https://www.youtube.com/watch?v=zlQEQQSqZ9g -> it's an old dream that others have had before.
MR4D 4y ago
Unfortunately, the world is scheduled to end (or reboot if you prefer) at 03:14:07 UTC on January 19th, 2038. [0] So, that means that the remake of an OS that we call a browser is likely to be the pinnacle of computing for our lifetimes. Hopefully after the Great Reboot of 2038, the next generation will learn from our computing mistakes, but since we've never learned from those that came before us, it's highly unlikely. But at least they will have to start from scratch, so there's a chance! [0] - https://en.wikipedia.org/wiki/Year_2038_problem https://en.wikipedia.org/wiki/Year_2038_problem
mch82 4y ago
> Like a world that never got past the horse and buggy At lunch one day a colleague explained that the size of the space shuttle could be linked to the width of two horses walking on a Roman road :-) One of my favorite lunch breaks of all time.

mdellavo 4y ago

It's not an open standard but the JVM spec is publically available and intended for multiple implementations https://docs.oracle.com/javase/specs/jvms/se8/html/ https://docs.oracle.com/javase/specs/jvms/se8/html/