I occasionally get asked why I prefer to develop in Java versus some of the powerful or flexible languages that are currently in vogue such as Ruby or PHP.  My response is that I tend to build a lot of enterprise software, for which Java is better suited. Enterprise generally refers to software built for business purposes, but it goes far beyond the intended audience. Enterprise software is generally:

• Very large in scope, with features in the thousands or tens of thousands.
• Intended to be used by a large set of users over a long period of time, sometimes several decades, with new, possibly complex and unexpected features being added over that time
• Developed by a large (relatively) and often frequently changing team, as required by a complex system needing a variety of specialists that is developed and maintained over decades.
• Built to meet certain standards of uptime, performance, and overall robustness so that users can rely on it to perform their jobs

This is not to say that Enterprise software is the better than other software, or more useful. Most of the software that we use, even at our places of business, does not meet these criteria. Consider the Windows Operating System versus the Google search engine. Both are ubiquitous for many computer users, and both are large, complex systems meant to be used over long periods of time, and were developed by large, changing teams. However, if google.com goes down (which I am not aware of happening in recent memory, but it's possible) we are frustrated and annoyed, but we can wait for it to return, or temporarily use a different search engine. If Windows crashes or otherwise fails to operate, we are essentially blocked from doing anything productive (short of installing Linux). As much as we all enjoy a few jokes about the robustness of Windows, in the long run you have to admit that it is held to an extremely high standard. The Google search engine is not Enterprise software, and the Windows Operating System is, for just this reason. Google does make enterprise software in the form of GMail and Google Docs, and they are quickly learning what a different world it is as they scramble to fix outages that leave their enterprise customers flailing and furious.

Java is especially suited for enterprise development because the complexity of the development process scales well as complexity of the application increases. Here is a simple graph that illustrates that concept:

This graph is my rough perception of how the complexity of the development process increases as the complexity of the application increases. At the low-end of the application complexity scale, the things that Java does for you to help you manage a large amount of code mostly get in your way. However, as the application increases in complexity, those things eventually start working in your favor and prevent things from getting out of control on the high end. Meanwhile, languages that are much better suited to that low to middle region shoot quickly upward.

Java specifically addresses, as part of its core feature set, the enterprise requirements called out above:

• Large feature set - Java expects that you will have a large code base supporting a large number of features. With core language and toolchain capabilities such as packages and jar files, Java expects that you will be decomposing your system into namespaces and reusable groupings. This helps manage a large code base, and provides a natural structuring of the code into named functional units. Very few other languages have such a heavy emphasis on helping you manage how your code is organized and released.
• Application used over long period of time with many modifications - With the near perfect platform independence of the JVM and libraries and dynamic linking, Java makes it easy to migrate to new platforms and to integrate with new tools.
• Developed by a large and changing team - Java is a great maintenance programming language. Pedantic features like the requirement that the package name match the folder name and the class name match the file name seem annoying at first (and nowadays if you are using an IDE, which I'm sure you are, you probably don't even think about it) are a godsend when you need to step into a new code base. Just look at the fully-qualified name of a class and you can more or less know where you ought to be able to find the .java file. Ever tried to track down a C++ class in one of the two dozen header files that are #included? It can be a nightmare, even with an IDE. Java is often criticized for its lack of features like multiple inheritance, mixins, operator overloading, dynamic method binding, or a preprocessor, but these things, while powerful in the right circumstances, can add a huge amount of complexity to a codebase while offering few if any capabilities that cannot be provided in another way. When you have a lot of developers coming and going on a project, its nice to know that they will spend their time writing new code and fixing bugs instead of trying to track down where some_random_ruby_method() is defined.
• Robustness - With compile-time type checking, automatic garbage collection, no ability for users to manipulate memory directly, simple stack trace facilities, and descriptive errors for most programmer error conditions, it is very easy to write a robust program in Java. Like the features in Java that help with maintenance, many of these features are often seen as drawbacks to those who are used to relying on them, but they often do more harm than good. There is a reason so many server applications are Java based nowadays.

So that's a long-winded way of answering the why Java question. I feel that it is the best tool for the kinds of systems I tend to build because it was created by people who understand the challenges of developing applications that meet enterprise software requirements.