Over the last couple of days vocal statements have been made about how the Java is a bad choice (Paul's being the most interesting).
I'd like to add another perspective on this topic, beyond what I'm saying in my latest installment of the Flinke Feder column in german Javamagazin which will be published in the 2010.12 issue and has been put online early because it fits pretty good with this week's news.
My statement here is that building on the Java platform is the best choice an established company can make today. Here's why:
The iceberg
Customer facing code is just the tip of the iceberg. Below the surface, often there are countless front/middle/backoffice systems running. There are massive IT infrastructures out there and related investments done in all sorts of businesses. This is money already spent. Billions. This software often is driving business (or even is business-critical), and their UIs are not the most important (yet often neglected) part of them. The business logic is the tricky part, and nifty language features are unimportant. Many other factors, however, are leading to Java. Just keep in mind that most middle- to-large-sized companies producing software are not in business of actually selling software.
Armies of Developers
If you've got a flock of dozens or hundreds of developers, you need to use a platform which is accessible, comprehensible and widely known. Your staff has to be able to concentrate on the business logic as far as possible. It's impossible for enterprises (except the very few) to hire only rockstar developers. By definition, exceptionally good programmers are rare. Banks, Telcos, web agencies, manufacturers tend to hire developers which have knowledge in their respective business domain. Startups, Google, Facebook and Fog Creek are a tiny, tiny fraction of the job market. The large part are average performing developers (like me *grin*) which need to be able to get the job done nevertheless. In these kinds of working environments, developers come and go, are reassigned or work on different projects in parallel. Project maintenance is transitioned between teams, internally or from builder to customer. Projects are completed and after weeks, month or years are revisited. The only constant (should I say static?) is Java. Most developers don't pick up a new computer language every year. They rather pick up their children and have a good time with their family, and by the way are happy to have a job they get done.
Freight containers
Most projects I see are developed on Windows workstations and deployed on Unix systems. JARs and WARs are the freight containers of software development.
Toolset
The rise of Java happened at the same time as the rise of open source. Companies are happy to take and use open source. It lowers development costs and lets people concentrate on the business aspects. The JDK offers a phenomenal integrated toolset. Java is supported by exceptional integrated development environments like Eclipse (or IntelliJ as far as I am concerned) which make it easy to navigate large code bases. There are tons of libraries out there.
Aversion to upgrade/Long-time consistency
People critize Java for being behind in evolution of language features. Now, if you look at how companies are adopting new versions of Java in their projects, Java is actually moving really quick. I'm still seeing projects running Java 1.4, simply because upgrading them to a more recent version is not a business case. SAP even pays Oracle to receive support for Java 1.4 until 2017! However, as soon as there is a business need, e.g. because you need to extend an application, upgrading the JDK is a no brainer. (Ruby, anyone?) The Java platform has never (or very rarely) seen changes introducing incompabilities. Enterprises love that.
Strict type checking/Relational DBs/Error handling
Bugs in software are very costly and hard to predict in project planning. So companies want to reduce the possibility of the average developer to introduce a bug. The compiler should be able to find as many potential bugs as possible. Java has strict type checking. RDBs have it, too. This goes together well. Whatever you think of checked exceptions, it's a fact that Java does not make it easy for developers to forego exception handling. Duck typing and monkey patching are powerful means when you have a code base you can control. Potential conflicting sub-projects and wide-spread dependencies just happen in large code bases. They should not go unnoticed.
Counting it all together, you might get frustrated
All these factors multiplied make Java the least-risky choice for companies today. I'm not trying to justify that. It's just a matter of fact. Try your bigCo to use Lisp for shorter, more elegant code. Or Ruby for more readable code. Or Erlang for better scalability. Or Python for less curly braces and punctuation. Or Javascript for prototype objects. I really hear you. We all are convinced of our own preferred weapon of choice. But in a complex corporate environment, each individual programmer's choice is potentially in conflict with what works for the company as a whole. So don't be surprised if you end up coding Java, again. It's ok.