3 ms·

Java and the JVM are in still in prolific use - the JVM is a terrific piece of engineering. It features prominently in a bunch of large-scale web architectures

Java and the JVM are in still in prolific use - the JVM is a terrific piece of engineering. It features prominently in a bunch of large-scale web architectures (be it as straight Java, Hadoop, Scala or whatever). Note of these are traditional enterprise or legacy environments. I've never seem a major schism in Java or the JVM on the scale of the split between Python 2.x and 3.x. All my installs require (_at least_) two versions of Python as a result. In fact it was only just recently that Debian/Ubuntu consolidated from shipping with 3 versions of Python to 2. If you're talking about install base then I guess you're limiting this to client apps - because none of the issues you mention are an issue for server environments... Unless you are running a dozen Java pieces of tech that all require a specific version? In the last 10-15 years I've only ever seen the need for two Java versions once. And that was on AIX. On POWER chips. And it was a vendor, not a technical requirement.

varjag 13y ago
JVM works, but let's not get carried away there. It still has method size limit of 64Kb here in 21st century, it is stack-based (reducing the possible optimization space considerably), and has no provisions for proper lexical scoping. People port languages to JVM for its ubiquity and massive amounts of library code, but I assure you none does it for some technical advantage.
- eonwe 13y ago
  I'd think that JVM JIT and GC count as technical advantages.
  - varjag 13y ago
    JIT is a feature to get around lack of performance in stack-oriented, archaic, bytecode VM. I'm not going to argue about it's practical performance merit, but it's not really an advantage over a native code compiler found in bunch of other languages (since it is a native code compiler itself). GC has arguably been the best thing Java brought along into mainstream, but it has been a solved problem for a while. The strategy that Java GC adopts, while a natural fit for Java and a host of other procedural languages, is suboptimal for many others.
    - eonwe 13y ago
      Could you perhaps expand a bit on what could be done on GC on non-procedural languages? I am suspecting that you mean that there are some tricks that could be employed by functional programming language runtimes. Hotspot GC is not the best there is for all uses (as Azul Zing JVM manages to forego stop-the-world collections altogether), but I am not aware that any popular runtimes have GCs that perform even close to JVM (perhaps .NET?) And for long running processes (where compilation time does not dominate), JIT is of course theoretically superior to AOT compilation.
- jwilliams 13y ago
  Why do you think the use of a stack reduces the optimization space? There are plenty of models for stack optimization. Even if you don't go down the purist track, plenty of approaches use register-allocation and optimize from there. Feels like an outdated CISC vs RISC argument. People also use the JVM because of it's Memory Model and robust threading.

varjag 13y ago

JVM works, but let's not get carried away there. It still has method size limit of 64Kb here in 21st century, it is stack-based (reducing the possible optimization space considerably), and has no provisions for proper lexical scoping. People port languages to JVM for its ubiquity and massive amounts of library code, but I assure you none does it for some technical advantage.

eonwe 13y ago
I'd think that JVM JIT and GC count as technical advantages.
- varjag 13y ago
  JIT is a feature to get around lack of performance in stack-oriented, archaic, bytecode VM. I'm not going to argue about it's practical performance merit, but it's not really an advantage over a native code compiler found in bunch of other languages (since it is a native code compiler itself). GC has arguably been the best thing Java brought along into mainstream, but it has been a solved problem for a while. The strategy that Java GC adopts, while a natural fit for Java and a host of other procedural languages, is suboptimal for many others.
  - eonwe 13y ago
    Could you perhaps expand a bit on what could be done on GC on non-procedural languages? I am suspecting that you mean that there are some tricks that could be employed by functional programming language runtimes. Hotspot GC is not the best there is for all uses (as Azul Zing JVM manages to forego stop-the-world collections altogether), but I am not aware that any popular runtimes have GCs that perform even close to JVM (perhaps .NET?) And for long running processes (where compilation time does not dominate), JIT is of course theoretically superior to AOT compilation.
jwilliams 13y ago
Why do you think the use of a stack reduces the optimization space? There are plenty of models for stack optimization. Even if you don't go down the purist track, plenty of approaches use register-allocation and optimize from there. Feels like an outdated CISC vs RISC argument. People also use the JVM because of it's Memory Model and robust threading.