JVM can run "Hello World" in about 50msec these days. The java guys do care about startup time, you can see if you read their mailing lists that they are constantly trying to defend their startup time as new features come in that add initialisation work. It's a priority.
Still, the reason many Java apps may feel like they start slowly is that they tend to do a lot. The app I'm currently working on starts in about 5 seconds, which isn't terrible by the standards of the space but isn't great either. But the reason is that that 5 seconds involves initialising an entire message queue broker, an entire relational database and an entire web server. These aren't tiny 'embedded' versions either: they're Artemis, H2 and Jetty, which are both also used standalone and have cutting edge featuresets. If we weren't using the JVM then we'd presumably be using some container based solution and starting postgres, some other MQ broker and apache or something. Bringing up such a container from scratch could easily take 5 seconds or more I think.
The JVM will by default use all the memory on your machine. This is an unintuitive default, to put it mildly. The reason is that the JVM can make your software run faster by using more memory. Doubling RAM is easy. Doubling your CPU cores whilst keeping them actually used is hard, doubling the speed of an individual CPU core at this point appears to be nearly impossible. So it makes sense in a technical way. But it does make it hard to judge memory bloat.
Again, speaking about the app I currently work on, I got a support request the other week from someone who wanted to run the app on a Raspberry Pi and was complaining it took much memory. Quick testing showed we actually only needed about 50-75mb of heap and simply telling the JVM to limit the Java heap to that size slaughtered memory usage and resolved the problem. Not hard to check that and configure things for small devices, but it's a knob you can't/don't need to twist when using manual memory management, or GCs designed for mobile/laptop devices where minimising memory usage took priority over raw runtime performance.
Honestly 5 seconds is an eternity when it comes to modern processors. I'm not convinced that it's a norm and I'm still wondering, what really happens, where that time goes?
"initialising an entire message queue broker, an entire relational database and an entire web server" is just abstract words. Initialization of an entire web server is creating a socket and binding it to 80 port, that's what should be done, but what else happens? Initializing a relational database is something like opening a file. May be read journal, rollback unfinished transaction, but those things could be done after initialization.
I use Java and I'm always trying to improve startup time. Last time I used undertow for tiny project, with jdbc to access remote database. Project started in mere milliseconds and it was much easier to iterate. But every time I enable something monstrous like servlets, hibernate, spring or, save god, java ee, it's always 30+ seconds start time. And I always wondered, why that's happens? I can serve millions of customers in those 30 seconds, I can read gigabytes of data from my HDD and parse millions of XMLs.
It's not so much the startup time (which is ~60ms), but warmup time. Assuming you're using a JITting JVM, it's compiling. There's now work on AOT compilation in HotSpot (and some JVMs already have it), but it really doesn't matter for big, long-running server apps, which are currently HotSpot's forté.
I haven't done startup profiling in detail but I'd expect most of the time to go on waiting for IO. CPUs are fast but opening a database, checking disk for queued messages etc is slow. Startup involves querying the database in our app, so the DB can't do that work after initialisation. There's also network traffic and RPCs happening in that 5 seconds too.
Without a doubt also some algorithmic waste in various libraries that aren't optimised for startup time. Startup time is rarely a metric that products compete on outside the consumer space, so improving it is not normally a priority.
And then yeah, finally the lack of AOT compilation. When Java 9 rolls around I plan to try and see how much difference it makes.
Still, the reason many Java apps may feel like they start slowly is that they tend to do a lot. The app I'm currently working on starts in about 5 seconds, which isn't terrible by the standards of the space but isn't great either. But the reason is that that 5 seconds involves initialising an entire message queue broker, an entire relational database and an entire web server. These aren't tiny 'embedded' versions either: they're Artemis, H2 and Jetty, which are both also used standalone and have cutting edge featuresets. If we weren't using the JVM then we'd presumably be using some container based solution and starting postgres, some other MQ broker and apache or something. Bringing up such a container from scratch could easily take 5 seconds or more I think.
The JVM will by default use all the memory on your machine. This is an unintuitive default, to put it mildly. The reason is that the JVM can make your software run faster by using more memory. Doubling RAM is easy. Doubling your CPU cores whilst keeping them actually used is hard, doubling the speed of an individual CPU core at this point appears to be nearly impossible. So it makes sense in a technical way. But it does make it hard to judge memory bloat.
Again, speaking about the app I currently work on, I got a support request the other week from someone who wanted to run the app on a Raspberry Pi and was complaining it took much memory. Quick testing showed we actually only needed about 50-75mb of heap and simply telling the JVM to limit the Java heap to that size slaughtered memory usage and resolved the problem. Not hard to check that and configure things for small devices, but it's a knob you can't/don't need to twist when using manual memory management, or GCs designed for mobile/laptop devices where minimising memory usage took priority over raw runtime performance.