JVM runtimes have a relatively high startup cost, are not often good 'citizens' in an instance running multiple types of software, and the build processes for a lot of JVM deliverables is an ungodly mess.
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.
I still don't understand some of this -- I developed in Java for 5+ years.
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.
I don't know if it's a standard Java thing or just an IntelliJ thing, but there's a setting that will hot-patch a running JVM when you change code. Things can get messy if you (or your dependencies) make assumptions about the ClassLoader being used, but other than that it works great.
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.
Comments
JVM runtimes have a relatively high startup cost, are not often good 'citizens' in an instance running multiple types of software, and the build processes for a lot of JVM deliverables is an ungodly mess.
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.
I still don't understand some of this -- I developed in Java for 5+ years.
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.
I don't know if it's a standard Java thing or just an IntelliJ thing, but there's a setting that will hot-patch a running JVM when you change code. Things can get messy if you (or your dependencies) make assumptions about the ClassLoader being used, but other than that it works great.
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.
Yeah, it's been a second since I've used IntelliJ/Spring, but I recall that being the case as well.
Gradle is something I've never messed with, but that makes sense.
I take it you haven't experienced the hell that is to deal with Hadoop JARs. It's absolutely ridiculous.