Why Java Sucks For Sysadmins

http://www.wekk.net/blog/2009/05/05/why-java-sucks-for-sysadmins/

by gnosis • 16 years ago

6 21 16 years ago

_delirium• 16 years 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.

dlsspy2• 16 years 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."

jcmhn3• 16 years 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.

dlsspy2• 16 years 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.

mattdw• 16 years 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• 16 years 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• 16 years 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.)

jcmhn3• 16 years 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.

fseek• 16 years ago

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

jcmhn3• 16 years 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• 16 years 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• 16 years 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_...

chrisbolt• 16 years 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!

pyman2• 16 years 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.

mahmud2• 16 years 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.

gnosis2• 16 years 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.

olefoo• 16 years 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.

Why Java Sucks For Sysadmins

Related Stories