8 ms·

Why Java Sucks For Sysadmins

6 points by gnosis 17y ago

_delirium 17y ago
Some of these arguments don't seem the best. Yes, the 'jar' command-line tool is much slower than GNU tar, but that's hardly conclusive proof that "Java is slow". It just means that 'jar' is slow. One generalization that's not unreasonable is that Java is bad for small tools with very short runtimes, because the VM startup overhead ends up being really expensive as a proportion.
dlsspy 17y ago
This is a terrible report. Some of it is just flat wrong (e.g. the perl error message only exists if you write it -- if the developer didn't check for errors, they just don't show up). Much of it is just "I haven't learned to do my job."
- jcmhn 17y ago
  > Much of it is just "I haven't learned to do my job." The point of the article is that java makes his job harder. There are standard tools (syslog, truss, ldd) that he uses to troubleshoot problems under unix, and java supports zero of them.
  - dlsspy 17y ago
    So... learn new tools? It's not hard to get the stack traces of every thread in a java vm at any point in time. It's not hard to get java using syslog if you really want it to (I wrote a syslog client for java, but ended up deciding it wasn't right for my problem). ldd typically doesn't make much sense in a java deployment, because people typically will publish all of the parts together in such a way that it's fairly obvious what pieces are in use. If we're all attached to all of our tools, we can never make progress.
    - gnosis 17y ago
      Maybe there just needs to be some good, brief "Java for sysadmins" docs that address some of the issues raised in this article and the comments in this thread. A bit of googling found this: http://stefanparvu.blogspot.com/2007/08/java-for-sysadmins.html http://stefanparvu.blogspot.com/2007/08/java-for-sysadmins.h...
mattdw 17y ago
Seriously? - he equates long jvm startup times with generally slow execution times. - he equates uncaught java stacktraces with properly displayed error messages from command-line tools - he gets frustrated that ldd and similar tools don't work on java apps - he equates the JVM startup overhead (syscalls) as meaning that a "hello world" program is overly complex, rather than, you know, an entire VM starting up. Basically, he has not the slightest clue about what Java is or how it works, and assumes it's just like all his c-language CLI tools. Which, obviously, it's not.
- mooism2 17y ago
  I thought his complaint about displaying stack traces in lieu of proper error messages was one of his more justified complaints. Granted, it's more of a java culture issue than a java language issue, but it's still java.
  - brazzy 17y ago
    A stack trace can be much more helpful in actually solving a problem than a "proper" error message. Of course it depends on the nature of the problem; I can see how it would be different for sysadmin-type problems (missing config file, etc.)
    - moe 17y ago
      Unfortunately such traces too often don't contain much useful information at all. The proper procedure would be to catch the exceptions and annotate it with something useful like 'Config file /etc/foo/bar not found'. From the Admin POV that's more helpful than a 200 line pamphlet boiling down to something like 'AbstractConfigFactory: nullPointerException'.
- jcmhn 17y ago
  > - he equates uncaught java stacktraces with properly displayed error messages from command-line tools Maybe that isn't fair, but there's something about java that seems to make programmers think that uncaught exceptions are an acceptable standard error exit. Or maybe I'm just really unlucky in happening to run into the problem over and over and over again.
jcmhn 17y ago
Preach it brother. Maybe java itself doesn't suck - I'm willing to give it the benefit of the doubt because a lot of fairly smart folks seem to like it. But a large number of real life java tools and programs suck. It's to the point where I shudder in revulsion every time I see the telltale indications that a solaris (or even worse - linux) tool is written in java - it promises a future that involves playing with 50 levels of shell wrappers to get a remotely meaningful error message.
skybrian 17y ago
This is a repost of an article that's at least a decade old. It has references to jre 1.1.8, green threads versus native threads, and so on.
ks 17y ago
On an otherwise idle 440MHz UltraSparcII running Solaris 8 with the Java 2 JRE 1.3.1, it takes jar over half a second just to report that it can’t find the file This article is clearly outdated. A lot has happened in the ten years since the 1.3 release. One example is that they discovered a bug in the jar code that made it much slower than it should be. http://blogs.sun.com/CoreJavaTechTips/entry/superduper_slow_jar http://blogs.sun.com/CoreJavaTechTips/entry/superduper_slow_...
- chrisbolt 17y ago
  Apparently not much has happened in the 9 years since the 1.3 release. Only in the last year did they fix something that was 10 times slower than zip to be only twice as slow as zip, and yet still... it's twice as slow!
pyman 17y ago
We, sysadmins, are not programmers. Our job is to configure and manage systems. We know nothing about machine languages. Most of us use scripting languages, like python and perl, to automate tasks. So please, don't ask me what the difference is between a Service and a Repository class, because I have absolutely no idea. It's Chinese to me. So, programmers, stay ways from me, stay away from my environments, and stay away from my procedural python scripts. Or I will replace you with a very small shell script.
- mahmud 17y ago
  We know nothing about machine languages. Not too long ago, sysadmins sent kernel and driver patches upstream. And the true Unix beards have a .gdbinit file per-kernel that's longer than your CV.
  - gnosis 17y ago
    Oh, please. If someone has the time to write kernel/driver patches and muck around customizing his gdb config, he's clearly getting paid to be a developer, not a sysadmin. Very, very few sysadmins have the luxury of spending time on this sort of thing.
    - mahmud 17y ago
      Seriously, haven't you ever met unemployed systems programmers? I have, they're a dime a dozen, and most happily take crappy admin jobs and 10-people insurance and travel agencies. I happily waited tables and poured coffee while writing compilers for fun. Technical competence does not in any way imply employment in the field.
    - pyman 17y ago
      Most sysadmins don't know low level languages such as C/C++. I know a few kernel developers myself, and they are all C hackers. If you write Linux kernel patches, then you are a programmer that a) works for a company that builds hardware b) needs a driver that doesn't exist. Lets get this straight. Adding data to an Excel spreadsheet using VBScript doesn't make you an Office developer, if you know what I mean :)
olefoo 17y ago
The problem as I see it, and it is still a problem even with java6 and prepackaged tomcat installations. Is that Java attempts to replace the OS rather than work with it. It should not be a pain in the ass requiring a helper shell script to print the pid of the running process to a file. And I'm sorry, but your code-browser may have a fancy gui for editing your xml configuration files. But I don't want to rely on having a GUI available to me. And reading raw xml even pretty-printed, is annoying. Also, memory and disk space are not infinite; networks are unreliable and slow; and executing binary code dispatched from other machines is a security risk even inside the vpn. If the java community cared about any of this they would have fixed it long ago, but as it is most java apps have a baroque suite of helper tools for deployment and management, and while they spew lots of internal information there seems to be some resistance to having them talk to syslog, and the process is not trivial.

6 points by gnosis 17y ago

Some of these arguments don't seem the best. Yes, the 'jar' command-line tool is much slower than GNU tar, but that's hardly conclusive proof that "Java is slow". It just means that 'jar' is slow. One generalization that's not unreasonable is that Java is bad for small tools with very short runtimes, because the VM startup overhead ends up being really expensive as a proportion.

dlsspy 17y ago

This is a terrible report. Some of it is just flat wrong (e.g. the perl error message only exists if you write it -- if the developer didn't check for errors, they just don't show up). Much of it is just "I haven't learned to do my job."

jcmhn 17y ago
> Much of it is just "I haven't learned to do my job." The point of the article is that java makes his job harder. There are standard tools (syslog, truss, ldd) that he uses to troubleshoot problems under unix, and java supports zero of them.
- dlsspy 17y ago
  So... learn new tools? It's not hard to get the stack traces of every thread in a java vm at any point in time. It's not hard to get java using syslog if you really want it to (I wrote a syslog client for java, but ended up deciding it wasn't right for my problem). ldd typically doesn't make much sense in a java deployment, because people typically will publish all of the parts together in such a way that it's fairly obvious what pieces are in use. If we're all attached to all of our tools, we can never make progress.
  - gnosis 17y ago
    Maybe there just needs to be some good, brief "Java for sysadmins" docs that address some of the issues raised in this article and the comments in this thread. A bit of googling found this: http://stefanparvu.blogspot.com/2007/08/java-for-sysadmins.html http://stefanparvu.blogspot.com/2007/08/java-for-sysadmins.h...

mattdw 17y ago

Seriously? - he equates long jvm startup times with generally slow execution times. - he equates uncaught java stacktraces with properly displayed error messages from command-line tools - he gets frustrated that ldd and similar tools don't work on java apps - he equates the JVM startup overhead (syscalls) as meaning that a "hello world" program is overly complex, rather than, you know, an entire VM starting up. Basically, he has not the slightest clue about what Java is or how it works, and assumes it's just like all his c-language CLI tools. Which, obviously, it's not.

mooism2 17y ago
I thought his complaint about displaying stack traces in lieu of proper error messages was one of his more justified complaints. Granted, it's more of a java culture issue than a java language issue, but it's still java.
- brazzy 17y ago
  A stack trace can be much more helpful in actually solving a problem than a "proper" error message. Of course it depends on the nature of the problem; I can see how it would be different for sysadmin-type problems (missing config file, etc.)
  - moe 17y ago
    Unfortunately such traces too often don't contain much useful information at all. The proper procedure would be to catch the exceptions and annotate it with something useful like 'Config file /etc/foo/bar not found'. From the Admin POV that's more helpful than a 200 line pamphlet boiling down to something like 'AbstractConfigFactory: nullPointerException'.
jcmhn 17y ago
> - he equates uncaught java stacktraces with properly displayed error messages from command-line tools Maybe that isn't fair, but there's something about java that seems to make programmers think that uncaught exceptions are an acceptable standard error exit. Or maybe I'm just really unlucky in happening to run into the problem over and over and over again.

jcmhn 17y ago

Preach it brother. Maybe java itself doesn't suck - I'm willing to give it the benefit of the doubt because a lot of fairly smart folks seem to like it. But a large number of real life java tools and programs suck. It's to the point where I shudder in revulsion every time I see the telltale indications that a solaris (or even worse - linux) tool is written in java - it promises a future that involves playing with 50 levels of shell wrappers to get a remotely meaningful error message.

skybrian 17y ago

This is a repost of an article that's at least a decade old. It has references to jre 1.1.8, green threads versus native threads, and so on.

ks 17y ago

On an otherwise idle 440MHz UltraSparcII running Solaris 8 with the Java 2 JRE 1.3.1, it takes jar over half a second just to report that it can’t find the file This article is clearly outdated. A lot has happened in the ten years since the 1.3 release. One example is that they discovered a bug in the jar code that made it much slower than it should be. http://blogs.sun.com/CoreJavaTechTips/entry/superduper_slow_jar http://blogs.sun.com/CoreJavaTechTips/entry/superduper_slow_...

chrisbolt 17y ago
Apparently not much has happened in the 9 years since the 1.3 release. Only in the last year did they fix something that was 10 times slower than zip to be only twice as slow as zip, and yet still... it's twice as slow!

pyman 17y ago

We, sysadmins, are not programmers. Our job is to configure and manage systems. We know nothing about machine languages. Most of us use scripting languages, like python and perl, to automate tasks. So please, don't ask me what the difference is between a Service and a Repository class, because I have absolutely no idea. It's Chinese to me. So, programmers, stay ways from me, stay away from my environments, and stay away from my procedural python scripts. Or I will replace you with a very small shell script.

mahmud 17y ago
We know nothing about machine languages. Not too long ago, sysadmins sent kernel and driver patches upstream. And the true Unix beards have a .gdbinit file per-kernel that's longer than your CV.
- gnosis 17y ago
  Oh, please. If someone has the time to write kernel/driver patches and muck around customizing his gdb config, he's clearly getting paid to be a developer, not a sysadmin. Very, very few sysadmins have the luxury of spending time on this sort of thing.
  - mahmud 17y ago
    Seriously, haven't you ever met unemployed systems programmers? I have, they're a dime a dozen, and most happily take crappy admin jobs and 10-people insurance and travel agencies. I happily waited tables and poured coffee while writing compilers for fun. Technical competence does not in any way imply employment in the field.
  - pyman 17y ago
    Most sysadmins don't know low level languages such as C/C++. I know a few kernel developers myself, and they are all C hackers. If you write Linux kernel patches, then you are a programmer that a) works for a company that builds hardware b) needs a driver that doesn't exist. Lets get this straight. Adding data to an Excel spreadsheet using VBScript doesn't make you an Office developer, if you know what I mean :)

olefoo 17y ago

The problem as I see it, and it is still a problem even with java6 and prepackaged tomcat installations. Is that Java attempts to replace the OS rather than work with it. It should not be a pain in the ass requiring a helper shell script to print the pid of the running process to a file. And I'm sorry, but your code-browser may have a fancy gui for editing your xml configuration files. But I don't want to rely on having a GUI available to me. And reading raw xml even pretty-printed, is annoying. Also, memory and disk space are not infinite; networks are unreliable and slow; and executing binary code dispatched from other machines is a security risk even inside the vpn. If the java community cared about any of this they would have fixed it long ago, but as it is most java apps have a baroque suite of helper tools for deployment and management, and while they spew lots of internal information there seems to be some resistance to having them talk to syslog, and the process is not trivial.