They talk about how under "Scalability" how "Java did not seem to fit the project requirements"... I'm sure a Java implementation can be less scalable than a node.js implementation, but every anecdotal piece of evidence I have experienced suggests that a good Java implementation will be faster than a good node.js implementation.
If we look to popular micro-benchmarks, they support my anecdotal observation:
On a side node: node.js also suffers from the issue that while a small node.js program might be fast, what is actually fast is the C code and as the program grows larger and increasing amounts of time are spent executing actual javascript its performance characteristics change dramatically. This fact seems often lead to unrealistic understanding of node.js performance due to people benchmarking very small examples.
This is less an issue with "very small examples" and more an issue of people throwing the practices out when they build more complex software.
Highly performant JS ends up looking a lot like C, and most of the off-the-shelf JS libraries that people use to build software are littered with '.call', '.apply', 'arguments', null/undefined/true/false usage, implicit type conversions, unnecessary closures, etc. All of these are cases that V8 doesn't optimize well, and because the libraries are built to be highly abstract and useful by using these, performance drops off precipitously. It's completely possible to write a large JS application that's competitive with Java in performance -- but nobody does it.
V8 hasn't even really begun optimizing these things, and they're going to be incredibly hard to optimize well. So perhaps a more apt question is: when JS VMs have as much time in the oven as the JVM has had, what will the performance look like?
If we look to popular micro-benchmarks, they support my anecdotal observation:
http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te...
http://www.techempower.com/benchmarks/
On a side node: node.js also suffers from the issue that while a small node.js program might be fast, what is actually fast is the C code and as the program grows larger and increasing amounts of time are spent executing actual javascript its performance characteristics change dramatically. This fact seems often lead to unrealistic understanding of node.js performance due to people benchmarking very small examples.