[podunkPDX]

I can’t speak to the actual act of Java development, but I can speak to Java applications from a sysadmin perspective (15 yr Sr. QA Engineer to a 3 yr Linux admin (don’t ask)) — I’ve got no real beef with Java from the development side, but maintaining some of those stacks in production is pure pain.

[lmm]

Huh? Java is probably the least demanding stack from the sysadmin side - no big chains of library dependencies, no docker, strong backwards compatibility that means you can fearlessly upgrade the language. All you have to do is keep an up-to-date JVM installed on your servers and deploy single-file fat JARs to them.

[smitty1e]

Then you get into managing a collection of Java projects where each on ships its own JVM and keystore to obviate version issues.

And then you have to deploy certificates against all that.

I'm not bitter.

[twic]

The keystore situation is indeed poor. For several years now, it has been possible to do more key management in-app, so you don't need to manage keystores (i have written programs which pull standard PEM-encoded keys from environment variables). But the practice of using a JKS keystore is so ingrained that it's very rare to make use of that.

[lovasoa]

Until you get an out of memory error. Then you need to start fiddling with the JVM.

Or until you realize that you have a 99th percentile latency of multiple seconds...

[lmm]

No language is immune to slow or memory-hungry code. The JVM is probably the easiest runtime to monitor/instrument/profile (and it's not like having no runtime makes that any easier, quite the opposite), and has probably the most tuneable GC going.

I guess enabling your users to do that might be work for a sysadmin, but that's more a reflection of those users having higher expectations for Java than for other runtimes - providing your users with the same capability in other stacks is never easier than Java, and often significantly harder.

[oblio]

There are only a bunch of out of memory errors, though. And they're easy to fix.