Why Java Sucks For Sysadmins | Hacker News Reader

Why Java Sucks For Sysadmins

wekk.net

6 pointsgnosis21 comments

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.

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.

> - 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.

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.

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.)

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'.

For CLI tools, yes, slow startup == slow execution.

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.

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.

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_...

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!

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.

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.

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.

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.

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 :)

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.

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."

> 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.

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.

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.h...

Reply on news.ycombinator.com