That depends on the filesystem, memory pressure, etc. Most JVM-based apps have quite a bit of filesystem I/O at startup, and a surprising memory footprint. If

That depends on the filesystem, memory pressure, etc. Most JVM-based apps have quite a bit of filesystem I/O at startup, and a surprising memory footprint. If the kernel's page cache is mostly full of dirty pages, that's a bunch of extra disk writes in order to free up RAM for the JVM. These startup benchmarks are typically not run with the JVM and application jars being pulled from NFS or AFS on a machine with a lot of dirty pages in the page cache. Some small sh/bash app using curl or wget to hit a REST API is going to have a lot less network and disk I/O in that case, even if bash and curl are being pulled from NFS/AFS. Many companies run JVMs from NFS/AFS to simplify deployment and management. Also, if the OP is logged into a server running the JVM-based CLI app, they may be running it on a server JVM and getting much more eager JITting. Maybe it's not fair to the JVM that there are lots of circumstances where things are accidentally tuned poorly for the JVM. On the other hand, there is a lot to be said for tiny apps that are pretty resilient to poor conditions. Sometimes size still matters, even on big servers with plenty of RAM and cores.