4 ms·

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 adm

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 5y ago
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.
- lovasoa 5y ago
  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 5y ago
    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 5y ago
    There are only a bunch of out of memory errors, though. And they're easy to fix.
- smitty1e 5y ago
  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 5y ago
    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.

lmm 5y ago

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.

lovasoa 5y ago
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 5y ago
  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 5y ago
  There are only a bunch of out of memory errors, though. And they're easy to fix.
smitty1e 5y ago
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 5y ago
  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.