Could you give some example oF unique features of the toolsuite around the jvm ?
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.
"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.
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.
In addition, the GCs and the compiler are pretty much the best in the business, and the next-gen compiler, Graal, is probably the biggest breakthrough in compiler technology of the past decade. Apart from jaw-dropping optimizations, it lets you control machine code generation.
Last but not least, critical parts of the standard library (though not all of it) -- such as the concurrency packages, which contains schedulers and concurrent data structures -- are of quality that is hard to match.
You're more optimistic than I am. And honestly proper TCO doesn't seem to be all that important to "regular" java programmers[1], it's just that it's crucial for $ALT_LANGUAGE implementers. (Where ALT_LANGUAGE has a functional flavor.)
[1] I'm guessing that this is the reason that it hasn't been prioritized... but who knows what complexity would rear its ugly head if one were to actually try to implement TCO on the JVM... I'd hazard a guess that it's 'highly non-trivial'.
BTW, there is a Scala compiler annotation that helps you check whether a function is tail-recursion optimized.
Scala supports local tail call optimization for a single function. A lot of FP languages support mutually recursive tail call optimizations, where two functions recursively call each other (common in FP). Scala (and no JVM language to my knowledge) cannot optimize this and so programmers have to resort to workarounds like Trampolines.
In contrast, LLVM IR and .NET CLR support it, allowing language compilers to use it. F# supports it and there's plans for C# to support it. It might be supported in the LLVM Scala target (Scala native) at some point in the future.
Being part of the largest, most successful, best tooled ecosystem in software is an Achilles' heel? Most people would (and should) gladly take that over any particular language feature.