Many of those bells and whistles are near-necessary in the enterprise world, but you have the accumulated mass of 'red zones' and developmental landmines in that ecosystem that can quickly turn you off it as a whole if you want to understand the whole system.
>JVM runtimes have a relatively high startup cost I think many people are okay with that when developing server software that's going to run weeks at a time. It can get a bit annoying with trying to rapidly iterate. And I think things are changing pretty quickly with AOT builds and general improvements.
>and the build processes for a lot of JVM deliverables is an ungodly mess.
I recall using "mvn package." That's it. This was on two different systems that served a good bit of traffic and weren't simple trivial projects.
Still not as good as C#'s debugger in Visual Studio (hit a breakpoint, edit the code, drag the execution back before the problem, resume and run the patched version) but nothing I've seen really is.
Setting up Gradle projects is a bit more involved depending on your setup, but in the end it's still a single command to build an executable JAR.
https://stackoverflow.com/questions/25120546/trick-behind-jv...
it sucks to use
many people believe otherwise, but those people have rich jvm experience, which is not easy to get
