4 ms·

I think JVM has come a long way, largely thanks to having the entire enterprise market incentivized to optimize the hell out of it, but at the end of the day it

by skohan 5y ago

I think JVM has come a long way, largely thanks to having the entire enterprise market incentivized to optimize the hell out of it, but at the end of the day it’s still an un-needed dependency.

heurisko 5y ago
I deploy things on the JVM running on two architectures. The "write once run anywhere" concept is still very useful, when required.
- skohan 5y ago
  You can also "write once run anywhere" with compiled languages. But you don't pay a virtualization penalty. The only advantage of a VM is that the actual executable artifact is platform agnostic.
  - heurisko 5y ago
    With Hotspot, hot areas of the code are compiled, lessening the virtualisation overhead. We compile some C libraries and use them via JNA. It takes time to create the cross-compilation environment with all the correct versions of the libraries they depend on (and the libraries that those libraries depend on). In comparison, if a library works on Java version x, we can include it and debug it running on the JVM as necessary.
jpgvm 5y ago
There are certain applications when it's far from an unneeded dependency. Namely building applications that are extensible by third parties, JVM allows very simple runtime class-loading and has the class loader hierarchy to make this good. If you want to build a plugin system in most compiled languages you are stuck with either dynamic linking which is unrestrained and much more likely to cause whole program failure or IPC, which imposes overhead. Then you have portable applications. If I want to run on many architectures and platforms the JVM allows me to do this easily, no need to worry about cross compilation or even multiple binary distributions. So yeah. Is it always necessary if you are always going to target the same platform as your dev environment and never load code dynamically? Probably not. Is the tradeoff (higher memory usage) generally worth it? I think so. Not for all cases, for these I do think you have to go with a compiled language with better memory usage characteristics but that is about it tbh. Previously the JVM also sort of sucked at latency sensitive workloads unless you were very careful not to upset the garbage collector. This is now a non-issue. ZGC and Shenandoah outclass the best latency optimised collectors in languages like Golang. So really that only downside remaining is memory overhead, I don't actually think that one can be eliminated - it's likely to remain the "can I use JVM for this or not" lynchpin for the foreseeable future. (ignoring things like GraalVM native images because I don't know enough about them to speculate on if it can substantially lower memory usage)
- skohan 5y ago
  I did not think about runtime extensibility, but that is a good use-case. At some point in the future, this might be solved neatly in a standards-based way with native WASM support
  - jpgvm 5y ago
    Thing is WASM is just trading one VM (JVM) for another. You could argue this is good because of baggage/support in JVM for more "dynamic" languages is out-dated but I think what will likely happen is your initially clean and fast WASM JIT will eventually succumb to a similar fate on the back of needing to support a wider range of guest languages than just Rust/C.
mavelikara 5y ago
> but at the end of the day it’s still an un-needed dependency. What are the alternatives you prefer to use?
- skohan 5y ago
  Compiled software.
  - mavelikara 5y ago
    Most compiled languages that have a minimal runtime need careful coding for memory safety. Rust attempts to solve this problem, at the expense of a huge initial learning curve. Go compiles to a static binary, has great cross-compilation tooling, and provides a runtime with memory safety. But many programmers find Go's abstraction capabilities too primitive. GraalVM provides an AOT compiler for Java [1]. In practice, this has proven to be a niche usecase [2]. [1] https://www.graalvm.org/reference-manual/native-image/ https://www.graalvm.org/reference-manual/native-image/ [2] https://openjdk.java.net/jeps/410 https://openjdk.java.net/jeps/410

by skohan 5y ago

I think JVM has come a long way, largely thanks to having the entire enterprise market incentivized to optimize the hell out of it, but at the end of the day it’s still an un-needed dependency.

heurisko 5y ago

I deploy things on the JVM running on two architectures. The "write once run anywhere" concept is still very useful, when required.

skohan 5y ago
You can also "write once run anywhere" with compiled languages. But you don't pay a virtualization penalty. The only advantage of a VM is that the actual executable artifact is platform agnostic.
- heurisko 5y ago
  With Hotspot, hot areas of the code are compiled, lessening the virtualisation overhead. We compile some C libraries and use them via JNA. It takes time to create the cross-compilation environment with all the correct versions of the libraries they depend on (and the libraries that those libraries depend on). In comparison, if a library works on Java version x, we can include it and debug it running on the JVM as necessary.

jpgvm 5y ago

There are certain applications when it's far from an unneeded dependency. Namely building applications that are extensible by third parties, JVM allows very simple runtime class-loading and has the class loader hierarchy to make this good. If you want to build a plugin system in most compiled languages you are stuck with either dynamic linking which is unrestrained and much more likely to cause whole program failure or IPC, which imposes overhead. Then you have portable applications. If I want to run on many architectures and platforms the JVM allows me to do this easily, no need to worry about cross compilation or even multiple binary distributions. So yeah. Is it always necessary if you are always going to target the same platform as your dev environment and never load code dynamically? Probably not. Is the tradeoff (higher memory usage) generally worth it? I think so. Not for all cases, for these I do think you have to go with a compiled language with better memory usage characteristics but that is about it tbh. Previously the JVM also sort of sucked at latency sensitive workloads unless you were very careful not to upset the garbage collector. This is now a non-issue. ZGC and Shenandoah outclass the best latency optimised collectors in languages like Golang. So really that only downside remaining is memory overhead, I don't actually think that one can be eliminated - it's likely to remain the "can I use JVM for this or not" lynchpin for the foreseeable future. (ignoring things like GraalVM native images because I don't know enough about them to speculate on if it can substantially lower memory usage)

skohan 5y ago
I did not think about runtime extensibility, but that is a good use-case. At some point in the future, this might be solved neatly in a standards-based way with native WASM support
- jpgvm 5y ago
  Thing is WASM is just trading one VM (JVM) for another. You could argue this is good because of baggage/support in JVM for more "dynamic" languages is out-dated but I think what will likely happen is your initially clean and fast WASM JIT will eventually succumb to a similar fate on the back of needing to support a wider range of guest languages than just Rust/C.

mavelikara 5y ago

> but at the end of the day it’s still an un-needed dependency. What are the alternatives you prefer to use?

skohan 5y ago
Compiled software.
- mavelikara 5y ago
  Most compiled languages that have a minimal runtime need careful coding for memory safety. Rust attempts to solve this problem, at the expense of a huge initial learning curve. Go compiles to a static binary, has great cross-compilation tooling, and provides a runtime with memory safety. But many programmers find Go's abstraction capabilities too primitive. GraalVM provides an AOT compiler for Java [1]. In practice, this has proven to be a niche usecase [2]. [1] https://www.graalvm.org/reference-manual/native-image/ https://www.graalvm.org/reference-manual/native-image/ [2] https://openjdk.java.net/jeps/410 https://openjdk.java.net/jeps/410