

Why Java Sucks For Sysadmins - gnosis
http://www.wekk.net/blog/2009/05/05/why-java-sucks-for-sysadmins/

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

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

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

------
ks
_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_...](http://blogs.sun.com/CoreJavaTechTips/entry/superduper_slow_jar)

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

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

------
dlsspy
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
> 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
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
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...](http://stefanparvu.blogspot.com/2007/08/java-for-
sysadmins.html)

