If you wanted to use a utility on your Linux (or other Unix) server box, and it required Java, and no other application on your server required Java, would you be turned off that you had to install it?

That is, do you look at that dependency and think "Bloat, security hazard, another system I have to maintain," or at this point is Java so safe and ubiquitous that it's no trouble at all?


Depends on a lot of things.

  1. What is the utility? How important is it, and are there non-Java alternatives?
  2. Why are you hesitating to install Java?
  3. What is the security profile of the machine?
  4. Sun Java or the one from your Linux distro (which is automatically updated)?

It's basically a tradeoff between the cost and the benefit. Java, like all apps, has security flaws. Sun updates their JVM every now and then and the Linux vendors that ship Java also do the same. How do you plan to push updates to this machine? How important is it? If the machine has proper firewalls and limited network daemons running, Java as an interpreter on the disk is probably not much of a hazard. Java typically doesn't run as root.

Almost any arguments that can be made about Java can be made about Perl, Mono, GCC, or any software that can run arbitrary code. Furthermore most Linux software is typically shipped by a distro, so you can often rely on the distro's updates to keep things secure. Sun Java, in this case, would be the same as any third party software. Does it matter if this third-party utility requires a library that happens to be Java? Maybe not.

The scenario is slightly different if you are talking about Java running a service application, such as Tomcat or JBoss, where Java is then listening to the network. In that case the security risk is higher. But you have the same security risks with any network-facing application such as apache or ssh.


I find it very very rare that no app on my linux server required java, and I don't have much of an issue with something requiring java. It is so widely used that I expect I'll need it at some point. This may be because most linux servers I have are for ERP systems.

I do have an issue with different apps wanting different version of the JVM or very very specific versions of the JVM though.

  • 1
    Thanks. Good point on the tight dependency on JVMs. Do you worry about having both 1.5 and 1.6 JVMs, or is the problem more like "I need 1.5_08b" ? Jul 10 '09 at 15:30
  • The very specific versions that an app maker would have(1.42.07 in my case). Of course with virtual solutions like ESX it isn't near as bad as it used to be since now I'll just bring up 4x ubuntu/centos servers and keep them separate. It isn't necessary, but it is much much less of a headache.
    – sclarson
    Jul 10 '09 at 16:09
  • 3
    I consider any Java software that won't run on the very newest 1.6 JVM in both 32 and 64 bit mode to be horribly broken.
    – Zan Lynx
    Jul 15 '09 at 6:19

It's a minimal risk. ANY software contains some risk, so it'd be incorrect to say it's no concern at all, but I have no special concerns about Java anymore compared to anything else. In the early days of Java, things were different though.


I look at that dependency and think "bloat, another system to maintain, and likely a PITA install". I don't think security hazard.

  • Fair enough. Is that enough to make you go look for another product, or do you just think, "Ug, oh well I'll give it a shot and see." ? Jul 10 '09 at 15:31
  • 1
    When VMWare replaced their web interface with a new one written in Java, requiring Tomcat, there were lots of complaints. Not because of Java per-se, but because Tomcat used up lots of RAM that could have been better put to running guest VMs. Bloat is a real problem sometimes.
    – gbjbaanb
    Jul 10 '09 at 15:33
  • I'll at least take a cursory look for another product. If nothing looks likely, and I do actively want this tool, I'll bite the bullet; it's not a deal-breaker.
    – chaos
    Jul 10 '09 at 15:44

I put Java in the same category as Python, Perl, Ruby, PHP, Mono or anything that needs a runtime. I have no problems with installing it as long as it doesn't require me to go find some custom classes, plugins or modules that conflict with the packaged version.

That said, being a sysadmin with Java apps tends to be a little time consuming as sysadmins would rather have error straight up, instead of reading through 3 pages of 'in stack...' errors to find an error like "empty string".

  • Sounds like that depends on the app in question, but yes I see your point that Java apps tend to dump crazy traces and log in weird ways (two lines per log entry?? are you kidding me??) Jul 10 '09 at 15:32
  • Java's design encourages a full stacktrace dump for errors, so that's what most programmers do as a default... Path of least resistance and all. :-) Jan 2 '14 at 19:48

Yes. I would think twice about it. In the case that I had no other Java app already running, I'd look for an alternative.

I'd rather not go to the pain of installing and configuring another system on my server if I couldn't help it. The same reason applies to everything else though - if I didn't need an email MTA on my server, I wouldn't install one. If I didn't run any Ruby apps, I wouldn't install Ruby.

However, if I did already have java installed and running, I'd install the new app and not worry about it. (but that's not what you asked!)


It should be noted that Java 4 / 1.4 has reached end-of-service-life and is no longer supported.

Java 5 / 1.5 will reach end-of-service-life in October this year


  • True, but there's lots of apps that "require" 1.4. (Whether they really do or not is another question, but many claim only that for support.) Jul 10 '09 at 16:16
  • That's what we have Java for Business for... Jul 16 '09 at 1:14

Not the answer you're looking for? Browse other questions tagged or ask your own question.