How extensive is your experience with other toolchains? Programmers notoriously use easy as a synonym for familiar and given how long Java has been around by now we'd have some evidence showing a major productivity advantage. Companies like Google with massive Java experience also investing heavily other languages suggests that this is not so compelling.
Being able to off-the-cuff use JMX to do realtime heap and stack analysis and then go deep with an offline heap dump (via Eclipse MAT, for example) is quite nice. On top of it you have a standardized interface for emitting counters and gauges. You can kind of get that through effort with other ecosystems (closest probably being .NET), but with the JVM it's just there and it's standardized. Have a memory leak that takes days of operation to manifest? Set up a trigger to heap dump at a certain time, then open up MAT and you can find some very subtle memory leaks and lock contention issues. Any JVM is basically running in a valgrind sandbox, with enough symbols to support a low overhead gdb connect, with a standard API for emitting meta-performance data.
All the above can be done in other environments, but generally with specially prepared deployments or executables, with choices being made along the way as to how to do it. I think the two key things are that in the JVM the heap is actually a quite structured database, which allows for introspection without recompilation or special tooling, and there's a standard mechanism for exposing detailed performance data.
Whether or not that translates into actual productivity differences is tricky. In my experience large companies tend to build their own equivalent and better-targeted tooling, and smaller companies increasingly pass their performance diagnostics to SAAS companies. It takes time to learn diagnostic tools and procedures in general, and in my experience a lot of Java teams don't know the tooling they have. I'd say the main productivity gain would be in quickly diagnosing production issues. You could argue that the JVM leads to software thinking that increases production issues by relying on long-running processes that need the stability to survive, but in my experience there are definitely niches where that is the only way to meet your performance goals.
>Programmers notoriously use easy as a synonym for familiar and given how long Java has been around by now we'd have some evidence showing a major productivity advantage
Have you ever heard the phrase "the dog that didn't bark?" You appear to be using an absence of evidence to prove evidence of absence, not to mention an argument from ignorance (which is always possible in our post-Gödel world).
That's a rather pretentious way to miss the point. The question was “Can you expand on this? Why do you think that?” and the response was a sweeping assertion and the name of a couple of products with no further details, or even a clear indication of which of the three languages mentioned further up-thread or others were being used as a basis for comparison. I wasn't asking for a peer-reviewed paper but even, say, “My team had a productivity loss when they switched to Go because [reasons]” would be better than nothing at all.
> java is very easy to troubleshoot compared to c, go, and rust
>> Can you expand on this? Why do you think that?
So the comparison is C, Go, and Rust. Yes, I'm familiar with all 3 of them and Java is easier to troubleshoot than either of them because it has better introspection out of the box.
That’s getting closer to what would have been an informative response. It could use further expansion but that could allow someone reading it to weigh how much that would remove a limiting factor in their experience.
For example, also having experience with all of them, the overall advantage over C is clear-cut but Rust is a lot less clear since stronger type system and better culture around package management and complexity avoids a lot of problems that otherwise require runtime troubleshooting.
Granted, a key part of that is really the question of whether you’re talking about a modern Java project or the more common enterprise Java sort with layers of accreted complexity and probably architecturally frozen at Java 8, where the problem is cultural rather than the language itself.
> That’s getting closer to what would have been an informative response. It could use further expansion but that could allow someone reading it to weigh how much that would remove a limiting factor in their experience.
Consider that you've gotten more useful information from my response than what you've paid for. If you want the whole picture, buy the book. Your sense of entitlement to more of my time seems misplaced.
>Companies like Google with massive Java experience also investing heavily other languages suggests that this is not so compelling.
Google's scale means that performance actually matters a lot versus productivity. When you've got millions of servers the costs add up. So making something twice as fast but taking 25% more dev time is probably a good tradeoff for them. For most other companies that's not the case.
