6 ms·

Okay, someone tell me why JVM isn't it? Is there something fundamentally flawed in the JVM that can't be fixed?

by kajaktum 3y ago

slj 3y ago
Oracle
- kaba0 3y ago
  Wrong answer. There is hardly a more open platform than the JVM, its reference implementation is open source, it has an open specification for both the language and the VM with plenty completely independent implementations, and is so big, running business critical infrastructure in basically almost every FAANG, that any single one would alone pay for its continuous development. Also, Oracle has been a surprisingly good steward of the platform, managing to retain almost the whole Java team from the Sun days (remarkably hard to do that at takeovers), increased the pace of its development and finished open-sourcing everything (formerly OracleJDK had proprietary extensions not found in OpenJDK, nowadays only some trademarked logos remain as the sole difference). So they mostly own only the name’s trademark, which is no big deal. Remember, google vs oracle happened over Sun’s license that explicitly forbade using their software on mobile devices. No such restrictions exist anymore in case of OpenJDK, which has the same license as the Linux kernel.
  - unnouinceput 3y ago
    Actually is the correct answer. Oracle and its shenanigans are the reason why I avoid their DB and Java.
    - kaba0 3y ago
      You do you, but that is a thoroughly uninformed emotion-based decision.
    - pjmlp 3y ago
      Hopefully you're in better terms with Google, given their stance into WebAssembly.
  - austin-cheney 3y ago
    I don't know why but discussions on WASM seem to be triggers for Java developer echo chambers.
    - kaba0 3y ago
      Anything of substance to add?
kaba0 3y ago
My somewhat grumpy answer would be that web people almost never do their homework. They are infamous for reimplementing things worse that were well available decades ago.
- 0x445442 3y ago
  You beat me to it. I thought we covered this ground 20 years ago.
  - treis 3y ago
    And rejected it because it was a nightmare of security issues and poor performance. The idea isn't bad. The implementation was.
- pie_flavor 3y ago
  All the problems with the JVM have been written up to death, and many are easily inferable from surface-level background knowledge. If you don't know them, who's not doing their homework?
  - kaba0 3y ago
    The only problem with the JVM were politics. Safety? Should have been whitelisting, nothing inherent with the JVM. Performance? We had shitty hardware back then, the improvements there alone would have solved the issue (see: we use Javascript), but especially today, the JVM is more than fast enough for most workloads.
    - pie_flavor 3y ago
      Fundamentally object-oriented, fundamentally garbage-collected, carries around a massive stdlib that's tightly integrated with precise functioning of the VM. And no, the performance concerns do not reduce to 'hardware'; the point is to eke out more performance than a high-level object-oriented garbage-collected system can muster. V8 is already on par with the JVM; if the JVM's performance was good enough for you, you'd just use JS.
samuba 3y ago
Quoting from Stackoverflow: - WebAssembly was designed with delivery-over-HTTP and browser-based in mind. For that reason, it supports streaming compilation - i.e. you can start compiling the code while downloading. - WebAssembly was designed to have rapid compilation times (resulting in web pages that load quickly), this is supported by having very simple validation rules compared to Java / JVM languages. - WebAssembly was designed with the concept of a 'host' environment, i.e. the browser. - WebAssembly was designed to be secure and simple, minimising the overall attack surface. - WebAssembly was designed to support a great many languages (C, C++, Rust, ...), whereas the JVM was initially design for a single language, Java. https://stackoverflow.com/questions/58131892/why-the-jvm-cannot-be-used-in-place-of-webassembly https://stackoverflow.com/questions/58131892/why-the-jvm-can...
flohofwoe 3y ago
Is there an easy to use C/C++ toolchain which targets the JVM? That may be the answer, because essentially that was what gave us WASM. Getting C/C++ code running in the browser was the motivation for Emscripten, and eventually this evolutionary branch gave us WASM (via asm.js). (and at the time there was plenty of competition: Adobe's Alchemy/Flascc which targeted Flash, and Google's (P)NaCl which compiled to native instructions and later (a subset of) LLVM bitcode, but notably, there was no similar attempt (that I know of) of a C/C++ compiler which targeted the JVM)
- pjmlp 3y ago
  Here you go, http://nestedvm.ibex.org/ http://nestedvm.ibex.org/
  - kaba0 3y ago
    Also, GraalVM has support for every LLVM language.
- ianopolous 3y ago
  I once wrote a Linux process emulator in java for static x86 binaries. It could run 80% native speed on x86 and 240% native speed on arm compared to gcc -o3. (I think gcc wasn't very good on arm at the time) Sadly it was proprietary.
pie_flavor 3y ago
The JVM requires a huge standard library, is tightly tied to implementation details of the host, is not easily compiled to by any language with stack types and pointers, embeds a number of historical mistakes, makes sandboxing basically impossible, and must be very carefully written if performance approaching native is required.
- kaba0 3y ago
  > is tightly tied to implementation details of the host Heh? > embeds a number of historical mistakes Well, you need history for that first. Wasm won’t be any different. > makes sandboxing basically impossible Why would it? It just turned out that whitelisting should be the default approach to security over blacklisting. There is nothing inherent in the JVM that would preclude one from doing that.
  - josephg 3y ago
    Safely sandboxing java is difficult because a lot of the standard library is written in native code with full filesystem access. And java code can dynamically load other java code. So its much easier for a security vulnerability in the standard library or runtime can quickly escalate into a RCE vulnerability. Java applets being secure largely depends on the entire JVM + JRE being secure. Given how massive that is, there have (of course) been many sandbox escapes over the years. Oracle's security vulnerabilities database[1] lists 730 CVEs in the java runtime environment. (They aren't all sandbox escapes but wow thats a lot!) WASM is far, far easier to reason about from a security perspective because its orders of magnitude simpler. There is no standard library. All wasm code (including any library code you compile in to your software) runs in an entirely encapsulated virtual machine with no ability to interact with anything outside of its little bubble. (Except for any functions the application explicitly passes in to the wasm module.) The wasm module boundary is fixed and simple, and as a result its much easier to secure. I'm sure someone will eventually find a sandbox escape for wasm code somehow. But I bet there'll be at least an order of magnitude fewer sandbox escapes in wasm than we've had with java because of the differences in the security model. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html https://www.cvedetails.com/vulnerability-list/vendor_id-93/p...
munificent 3y ago
Static initializers, and bytecode verification make it much harder to get fast application startup. Class loaders, reflection, all methods being virtual, and iteration going through an interface make it much harder to get good performance with the complexity and warm-up time of a JIT. Type erasure and single polymorphic dispatch makes the JVM's object representation a weird fit some languages. UTF-16 strings are just awful. Oracle's business practices rightly scare people away from wanting to build on top of anything they control. The JVM is a very impressive technology, but it's also almost thirty years old and we've learned a lot since then.

Okay, someone tell me why JVM isn't it? Is there something fundamentally flawed in the JVM that can't be fixed?

slj 3y ago

Oracle

kaba0 3y ago
Wrong answer. There is hardly a more open platform than the JVM, its reference implementation is open source, it has an open specification for both the language and the VM with plenty completely independent implementations, and is so big, running business critical infrastructure in basically almost every FAANG, that any single one would alone pay for its continuous development. Also, Oracle has been a surprisingly good steward of the platform, managing to retain almost the whole Java team from the Sun days (remarkably hard to do that at takeovers), increased the pace of its development and finished open-sourcing everything (formerly OracleJDK had proprietary extensions not found in OpenJDK, nowadays only some trademarked logos remain as the sole difference). So they mostly own only the name’s trademark, which is no big deal. Remember, google vs oracle happened over Sun’s license that explicitly forbade using their software on mobile devices. No such restrictions exist anymore in case of OpenJDK, which has the same license as the Linux kernel.
- unnouinceput 3y ago
  Actually is the correct answer. Oracle and its shenanigans are the reason why I avoid their DB and Java.
  - kaba0 3y ago
    You do you, but that is a thoroughly uninformed emotion-based decision.
  - pjmlp 3y ago
    Hopefully you're in better terms with Google, given their stance into WebAssembly.
- austin-cheney 3y ago
  I don't know why but discussions on WASM seem to be triggers for Java developer echo chambers.
  - kaba0 3y ago
    Anything of substance to add?

kaba0 3y ago

My somewhat grumpy answer would be that web people almost never do their homework. They are infamous for reimplementing things worse that were well available decades ago.

0x445442 3y ago
You beat me to it. I thought we covered this ground 20 years ago.
- treis 3y ago
  And rejected it because it was a nightmare of security issues and poor performance. The idea isn't bad. The implementation was.
pie_flavor 3y ago
All the problems with the JVM have been written up to death, and many are easily inferable from surface-level background knowledge. If you don't know them, who's not doing their homework?
- kaba0 3y ago
  The only problem with the JVM were politics. Safety? Should have been whitelisting, nothing inherent with the JVM. Performance? We had shitty hardware back then, the improvements there alone would have solved the issue (see: we use Javascript), but especially today, the JVM is more than fast enough for most workloads.
  - pie_flavor 3y ago
    Fundamentally object-oriented, fundamentally garbage-collected, carries around a massive stdlib that's tightly integrated with precise functioning of the VM. And no, the performance concerns do not reduce to 'hardware'; the point is to eke out more performance than a high-level object-oriented garbage-collected system can muster. V8 is already on par with the JVM; if the JVM's performance was good enough for you, you'd just use JS.

samuba 3y ago

Quoting from Stackoverflow: - WebAssembly was designed with delivery-over-HTTP and browser-based in mind. For that reason, it supports streaming compilation - i.e. you can start compiling the code while downloading. - WebAssembly was designed to have rapid compilation times (resulting in web pages that load quickly), this is supported by having very simple validation rules compared to Java / JVM languages. - WebAssembly was designed with the concept of a 'host' environment, i.e. the browser. - WebAssembly was designed to be secure and simple, minimising the overall attack surface. - WebAssembly was designed to support a great many languages (C, C++, Rust, ...), whereas the JVM was initially design for a single language, Java. https://stackoverflow.com/questions/58131892/why-the-jvm-cannot-be-used-in-place-of-webassembly https://stackoverflow.com/questions/58131892/why-the-jvm-can...

flohofwoe 3y ago

Is there an easy to use C/C++ toolchain which targets the JVM? That may be the answer, because essentially that was what gave us WASM. Getting C/C++ code running in the browser was the motivation for Emscripten, and eventually this evolutionary branch gave us WASM (via asm.js). (and at the time there was plenty of competition: Adobe's Alchemy/Flascc which targeted Flash, and Google's (P)NaCl which compiled to native instructions and later (a subset of) LLVM bitcode, but notably, there was no similar attempt (that I know of) of a C/C++ compiler which targeted the JVM)

pjmlp 3y ago
Here you go, http://nestedvm.ibex.org/ http://nestedvm.ibex.org/
- kaba0 3y ago
  Also, GraalVM has support for every LLVM language.
ianopolous 3y ago
I once wrote a Linux process emulator in java for static x86 binaries. It could run 80% native speed on x86 and 240% native speed on arm compared to gcc -o3. (I think gcc wasn't very good on arm at the time) Sadly it was proprietary.

pie_flavor 3y ago

The JVM requires a huge standard library, is tightly tied to implementation details of the host, is not easily compiled to by any language with stack types and pointers, embeds a number of historical mistakes, makes sandboxing basically impossible, and must be very carefully written if performance approaching native is required.

kaba0 3y ago
> is tightly tied to implementation details of the host Heh? > embeds a number of historical mistakes Well, you need history for that first. Wasm won’t be any different. > makes sandboxing basically impossible Why would it? It just turned out that whitelisting should be the default approach to security over blacklisting. There is nothing inherent in the JVM that would preclude one from doing that.
- josephg 3y ago
  Safely sandboxing java is difficult because a lot of the standard library is written in native code with full filesystem access. And java code can dynamically load other java code. So its much easier for a security vulnerability in the standard library or runtime can quickly escalate into a RCE vulnerability. Java applets being secure largely depends on the entire JVM + JRE being secure. Given how massive that is, there have (of course) been many sandbox escapes over the years. Oracle's security vulnerabilities database[1] lists 730 CVEs in the java runtime environment. (They aren't all sandbox escapes but wow thats a lot!) WASM is far, far easier to reason about from a security perspective because its orders of magnitude simpler. There is no standard library. All wasm code (including any library code you compile in to your software) runs in an entirely encapsulated virtual machine with no ability to interact with anything outside of its little bubble. (Except for any functions the application explicitly passes in to the wasm module.) The wasm module boundary is fixed and simple, and as a result its much easier to secure. I'm sure someone will eventually find a sandbox escape for wasm code somehow. But I bet there'll be at least an order of magnitude fewer sandbox escapes in wasm than we've had with java because of the differences in the security model. [1] https://www.cvedetails.com/vulnerability-list/vendor_id-93/product_id-19117/Oracle-JRE.html https://www.cvedetails.com/vulnerability-list/vendor_id-93/p...

munificent 3y ago

Static initializers, and bytecode verification make it much harder to get fast application startup. Class loaders, reflection, all methods being virtual, and iteration going through an interface make it much harder to get good performance with the complexity and warm-up time of a JIT. Type erasure and single polymorphic dispatch makes the JVM's object representation a weird fit some languages. UTF-16 strings are just awful. Oracle's business practices rightly scare people away from wanting to build on top of anything they control. The JVM is a very impressive technology, but it's also almost thirty years old and we've learned a lot since then.