> Java itself isn't necessarily slow, it's the application design.
Java itself is a language, and cannot be slow or fast. However, the most popular (and thus well-supported) implementations of Java are slow. On those implementations, the idiomatic way of writing Java leads to massive amounts of memory allocations, which force Garbage Collector to allocate much more memory than it needs and perform complex collection strategies. Many allocations also destroy memory locality and completely negate the effect of CPU cache.
> Would it benefit from being compiled with GraalVM?
Maybe, maybe not. But GraalVM, at least for now, is not the standard way of running Java programs.
I think the point of the parent comment was that it's bad to choose Java for anything other than long-running server-side applications (where JIT compilation with Hotspot might actually prove valuable for squeezing out those last few percent of throughput). For anything else, Java is really a sub-optimal choice - the startup time is horrible, the speed is not really great, and the JVM maintenance is painful. For a build tool, which is invoked many times to do relatively small amounts of work (compared to long-running server-side applications), it just doesn't make sense.