Not the parent but: Java has a long tradition of reimplementing things in Java rather than relying on system libraries. Everything from OpenSSL to tzinfo to libpng has its own Java implementation, entirely separate from anything else on the system.
> Java has a long tradition of reimplementing things in Java rather than relying on system libraries.
Er, that’s kind of the point of the Java Virtual Machine… It keeps you from tying your application to a particular system architecture.
I’ve noticed that JVM administration tends to fall into the “no man’s land” between devs and admins: Devs figure that the Admins will take care of it, and Admins are annoyed that they need to use a separate set of tools to admin the Java apps (and are not eager to learn them.)
Web browsers do the same thing, they vendor everything they can to make the cross-platform experience better. Given that browsers are pretty much full-blown SDKs these days, and with everything being deployed as either a web app or an Electron app, I think it's fair to say that Chrome and Firefox are the new Java.
I am not admin, but kind of manage non-prod servers. One problem with Java is that a lot of things are half-done. If it totally relied on OS it would have worked, or if Java solution was thorough it would have worked. SSL management and Java app monitoring with tools like jconsole comes to mind. But others might have different annoyances.
It is working on one server and then broke on a newly built server apparently due to some network settings which devs/ app admins are not aware of.
I don’t think this is Java itself. Many Java apps are not designed with admin UX in mind. Those that have good UX usually don’t land on admin’s plate anyway and are managed by devs or devops.
jconsole is not user developed Java app, it is built-in tool comes with JDK distribution. And problem was not with UI it was that UI wouldn't come up because of some obscure network setting, with no useful error displayed back to user to fix issue.
