Does this mean ...
No. We are going to compare Apples and Oranges here.
Node.js's non-blocking asynchronous event-driven processing model spawns new threads automatically for all kind of I/O activities (network, HDD, Block-devices, etc.). Node.js uses a stack and command-queue to manage tasks. The command-queue helps to keep the CPU and memory pressure low.
Java network libraries/frameworks typically spawn new threads programmatically per request which adds more pressure to CPU and memory management. The CPU spends more time on swapping memory code pages and switching between processes and threads, the more requests coming in.
Node.js can't gain more speed from CPUs with more CPU cores; Java benefits from more cores pretty quickly. Node.js can't access high amount of memory without tuning it's embedded V8 engine via command line parameters; Java benefits from more memory pretty quickly, it only takes some few start parameters.
A typical Node.js machine has only 2 or 4 CPU cores and something around 2GB or 4GB of RAM memory. Because you can't get more performance without further tuning and experiment with V8 parameters. Running benchmarks on the same machine for Node.js and Java lets Java look pretty silly.
And we still can't compare Node.js and Java easily. Vert.x is a project trying to enable Node.js's processing model for Java developers. Vert.x benchmark scenarios were abusing unknowingly Java build in mechanics, rendering Vert.x results much higher than Node.js's results. Java buffers files in memory if the file size is small enough. Each time accessing the file serves its content from RAM, which is much much faster than any HDD or SSD. Node.js assumes the content may change and reads the file fresh. Using the same buffer trick for Node.js renders both pretty much equal regarding speed. Bombing both with thousands of requests per second let's look Java silly again - if the machine is a typical Node.js machine. Adding queues to Vert.x renders them both equal again. We can continue here for long.
We can't compare them both fair enough. The environment dictates the winner. It turns out that a thousand small-machines are faster than one big-machine; powerful enough like thousand small-machines. It also turns out that a thousand small-machines are cheaper than one big-machine; powerful enough like thousand small machines. In such environments, Node.js wins. Not even comparing developer experience and developer productivity. Hint: Download, install, run, GG ;-)