Very fast.

Unicode strings.

Some measure of type checking (probably appeals more to large, enterprisey projects). This also makes IDE autocomplete easier.

Lots of libraries.

Cross platform.

And yes, a large pool of developers.

Not too many languages can check off all those boxes, making Java a sweet spot for a lot of enterprise development. Probably not a good fit if you just want to throw together a CMS, though.

Here are our simple reasons:

* The JVM is fast.

* The JVM can take proper advantage of multiple cores directly (no GIL).

* The JVM is efficient compared to other runtimes.

* Java is type-safe.

* There's a library for everything, and libraries are generally well-documented, unit-tested, and provide stable releases with binary/source-stable APIs.

* There are a number of alternative languages to choose from that can interoperate on the JVM (Scala, Clojure, JRuby, ...)

I've worked with plenty of JVM/Java-based projects that shipped quickly. There genuinely isn't anything else I would use server-side.

The reality is that most enterprise projects are generally so many layers of lasagna code that JVM performance is about 20 down on the list of things to blame for poor performance.

... except those are the reasons our organization uses Java.

Unfortunately, it seems like this doesn't fit the narrative that some people want to have about the JVM and Java.

Perhaps, but you can't ignore the reasons that the inertia and labor pool came to be in the first place, many of which nupark2 lists and which are still valid.

* There are a number of alternative languages to choose from that can interoperate on the JVM (Scala, Clojure, JRuby, ...)

I've worked on contract in large and small companies, and the amount of paperwork to go through in large companies is ASTOUNDING. For example, we once had to get a test account created in the test domain (not even production). It took 23 emails, 4 IT requests, and 6 hours to complete--and that was the "accelerated" path.

But bureaucracy is only part of it. The real reason it takes a company to build something so freaking long is testing. Not just test-driven development (that's crazy talk, by the way), we're talking testers. Lots of them. Now, I'm all for testing (yay testing), but companies go to the extreme. I've had more than one of my projects take three to four times as long to test as they took to develop. Sometimes you luck out and get really good testers, though, so then life is peachy.

But to answer your question about why companies use Java, it's because it's widely taught, and programmers are thought of as interchangeable pieces. They can bring over a ton of people from out of the country for cheap labor, or just hire a bunch of D+ CS students and put them in cubes and give them detailed specs and just let them go at it. There's no thought to it--they're cogs in a machine.

Also, sometimes technology choices are just at the whim of people higher up--they have a favorite technology and push that as "the way," even in situations where it doesn't quite fit. Such is life.

To sum up, companies are slow to develop because of overhead and bureaucracy, and they use things like Java because they want cheap programmers, not good ones.

Edit: I should clarify something that came off as really presumptuous and pompous. Java isn't a bad technology, per se, and there are plenty of great programmers who use it. My point was that Java developers are easy to find cheap, so that puts a vote in the win column for larger enterprises.

That being said, there are a lot of really good reasons to use Java, and if you know Java really well, you can put together a CMS as fast (if not faster) than somebody slinging PHP or Python or whatever their language of choice is.

My main goal was to address why enterprise development is often considered slow by startup standards, and what causes that. I know a few really great Java programmers in big enterprises, and I know they often get frustrated by the glacial pace of enterprise development.

Autocomplete also makes life staggeringly easier, as do strong refactoring tools.

Not having to deal with memory management is also a big plus.

When you put those requirements together you end up with C#/Java. Which is why a fair number of places whack together UIs in C# and server side code in Java.

Sure, plenty of web apps can run fine on Ruby, but even then, many of them start looking towards a language thats easier to maintain.

Startup founders and small businesses tend to have more talent available to them. When you have 4 guys with MIT degrees you can hack through problems so you don’t need support. But if you’re a big company you sometimes have to settle for the day laborer. The guy who can do the grunt work coding but who slams on the brakes when he runs into any kind of problem.

As someone running a shop with those type of workers you have a choice. Have them wait for one of the more senior people to help them or throw $300 at the problem and have them call support.

This doesn’t produce the most elegant code but most big companies aren’t interested in that anyway. If it works and crashes relatively rarely most corporations are fine with it.

Unrelated to that it should also be mentioned that companies like IBM and Microsoft market to non-IT execs where as open solutions don’t have marketing departments. There’s a reason they say “No one ever got fired buying Microsoft”

As for team delivery speed it is certainly possible to deliver quickly. The dynamic languages have definite advantages over Java. There is less XML/property/configuration stuff to manage for instance. But the Java frameworks are actively developed and they get better all of the time too. Delivery speed is mostly a team and organization thing. Large orgs can take forever to deliver the simplest of things. It can take forever for people to decide what they want. You might have to get permission from three different VPs. You may have to schedule a series of meetings to have a decision made and it can take a couple of weeks the find time when all stakeholders have open time on their calendars. You may be dependent upon cooperation and resources from another team that isn't really motivated to help you because they have their own stuff going on. So it's not really a technology problem, it's a management problem.

So as a common-denominator for large codebases with average-quality developers it makes sense in the long term, although it's not terribly fun.

But, for example, many of our webpages are made with PHP using some CMS (Typo3) because it's perfect for this. Our mobile site uses our Java webservices from PHP too.

I've been working with JEE (formerly J2EE) and JSE for some ten years and I know of Java's (platform and language) problems, but I think that they are surpassed by its capabilities, tools, resources availability, etc.

Do I want Java to go away? Why I ask? It works! It's not perfect, is not shiny, is not "agile", but it gives management that warm feeling of cash flowing in. Oh! And it gives me a job!

Java is stable, has plenty of libraries, lots of tools, is friendly to refactoring, testing, and it is not such a bad language. Just take a look at the tools developed in java by good teams (eclipse, apache, joss, spring and so on..)

When Java debuted, it was a Big Deal, and promised faster development, garbage collection, and multi-platform deployment to enterprises. As I see it, "enterprise" was (is) Java's primary customer. One they picked Java (likely more than a decade ago), there has to be a significant reason to change (remember, big companies tend to be risk-averse), and there hasn't been anything better enough to justify changes to the enterprise. Also, the big ERP systems use Java, so companies need embedded knowledge and consultant perpetuate the cycle. If you think getting them off of Java is hard, I worked for a company (a bit more than five years ago) where significant effort was spent getting them to Java, off of monolithic C.

As to your other question, yes, I know of very successful (multi-hundred MM (USD) revenue) that use Java in Agile teams. A company I'm starting to work with has several agile teams; some teams use scrum, some use kanban. So yes, they use it, and yes, it's successful.

Don't try to force your worldview too much on companies. As you get older, you'll find there are many good (and often several not-so-good) reasons for them being the way they are. they have the benefit of thousands of person-hours of experience. You (we) don't, yet.

When you've got a project with dozens of teams and hundreds of components having things like static typing and well designed exception are really important to ensure data integrity.

There are also many features that languages like php lack, such as multithreading and atomic operations.

How did the ecosystem grew so big? Java is free and is easier to learn and faster to develop, compared to other "big players" (e.g. C++)

Besides, most big enterprises are already paying IBM/Oracle/Jboss/etc for Websphere/MQ/ or whatever App Server and support; it makes sense to use it anyway.

I would say it's mainly inertian and (perceived) risk management. BTW, I believe the Java camp got alot of things right, but that's another story.

When I was doing Java coding, guys would argue in boardrooms for months about design patterns and system architecture, looking fairly important to the boss, never really getting anything accomplished. I was so glad to switch all that to a forward-thinking company that used PHP and PostgreSQL -- we knocked out code really fast and spent less time arguing in boardrooms. Sure, we used design patterns, but we didn't get overly academic about it like the Java guys did.

Now, anyone trying to introduce PHP or PostgreSQL into a Java/Oracle shop would find it really hard. These guys want to keep their certifications relevant. The Java guys will say that PHP is a hack with the inconsistent parameters, and claim it's nothing more than juked up Perl. If they permit it at all, they'll call it a "template language" to be used only for the front-end. The Oracle guys will say that PostgreSQL isn't battle-tested enough like Oracle, lacks sufficient replication and migration tools, and tell you the tech support for it isn't as good as Oracle's. Then they'll scold you for considering PostgreSQL over MySQL since Oracle owns MySQL now. And when they go in that direction, they'll say, "Yeah, MySQL is great only for tiny stuff."

As for "rapid development teams using Java" -- LOL, that doesn't exist as far as I've seen in the Fortune 1000 companies I've worked in. Rapid, as in take 1 year to argue about the system design before you start coding it? Yeah, that's about how rapid it is.

I'm not a developer but I think at least part of the reason for building in java is the abundance of libraries (i.e. Apache Commons). We also just do POJOs/Servlets so development can be rapid. I think most people think of J2EE when they think of big companies and java.

And that forced language structure can function as a rudimentary safety net for mediocre programmers.

From a large company's point of view, it is a cheap and homogenized programming force. You, I and Joel Spolsky might care about the "good" programmer that massively outperforms other programmers. Most businesses want cheap and reliability.

Add to that a market of off-shores and other workers that fit the "cheap" bill and you end up with dominance. When's the last time you saw a H1B that programmed in Haskell?

* The JVM is fast compared to VBScript type languages and slow compared to language that use C libraries (Python). There are benchmarks about how JVM is very fast at crunching numbers however in practice I have written very little code that is math I tend to use a library (math libraries written in C/Fortran). Most applications are moving bits around and are thus IO bound and so languages that can quickly be modified to use better caching or more complex data access algorithms will perform better. Enterprise web apps that use Java and are fast are the exception not the rule.

* JVM is a memory hog. Now this could be blamed on all the dependencies but even writing a very simple JSON web service is going to cost you a lot of memory. This makes compilation slow and development slow.

* Dependency management is a mess. Maven is helpful but is exceptionally slow with just a few dependencies.

* Multithreaded Java has never been as robust or fast as multiprocess applications I have see run in other languages. I have seen robust multiprocess Java applications but they tended to run per node because of memory usage and performance. I would say I am above average developer and have written and rewritten a good amount of thread code and the more I do the more I am convinced it is a horrible concurrency model for non super human developers.

PHP may make some inroads over time since it has a good base of people that can be hired. However I see it mostly to be used as an outsourcing tool when a project need to get done quickly. This is just my experience over the last 14 years so YMMV.

To understand it we have to look at the history of when Java came about and what Java brought to the table. Most people think it was a more modern language that was what won but the reality is that was just icing. The real winner for Java taking over was the VM, at the time Unix was dominating the server space (in particular Solaris) but Microsoft has a through monopoly on the desktop. So here you had all of development on one OS and all of the runtimes on another, The promise of Java was that your developers could continue to develop on desktops while delivering to Server architecture, it was not always totally smooth but it did work and their in lies the revolution that Java brought. A common development platform across architectures. It seems so common today but at the time it was huge, it had the potential to save companies millions if not billions.

Fast forward to today and a big issue with the enterprise is labor, and lets face it trying to take the road less traveled can introduce unnecessary risk into the enterprise. If a company is not in the Vally the quest to find a Ruby or Python or Node.js developer can result in not finding a single candidate, this is far more risky than another month of development time to stay with Java. They are totally different concerns, a small scrappy start up, can afford to kick the bushes of local groups to find a guy playing around with Node.js, an enterprise has no systematic way of figuring out if the kid at the local users group is an expert at Node.js or has just been playing with it for 2 weeks. To me this is the biggest one, talent is available locally and even if it is not, the big vendors and even the recruiters can dig someone up fast. This alone mitigates a lot of risk from the organization.

Second most enterprise software is built with Java and has Java API's, SAP, Oracle, IBM and many of the other offerings these guys use are in Java. I like to poke a lot of fun at some of those systems but the reality is implemented correctly they can save a lot of money and time and unlike in a start-up where every penny counts in the enterprise vendor supported systems are considered a good thing. They allow the company to focus on their core business while leaving system development to a vendor.

Which brings me to my last point, there is a new revolution underway, and I do believe that in the near future the cost benefit analysis is going to be so great that the enterprise will not be able to ignore it, and that revolution is SaaS. For the same reason I just highlighted, (focusing on core competency), SaaS will be huge, now not only will the enterprise not have to concern itself with maintenance of custom systems, but they will be able to offload support as well as infrastructure. Getting out of the infrastructure game for the enterprise will be huge and may herald the end or Java's dominance.

A good talk on this is "Twitter: From Ruby on Rails to the JVM" by Twitter's app services chief Raffi Krikorian http://ontwik.com/rails/oreilly-oscon-java-2011-raffi-krikor...

The fact that Twitter just hired Oracle's Adam Messinger as its new CTO seems to be a strong sign this direction is continuing. http://techcrunch.com/2011/11/07/twitter-nabs-former-oracle-...

Certainly languages like Ruby and Python will continue to post performance gains as their interpreters mature. Certainly the migration of e.g. Lisp (Clojure) and Ruby (JRuby) to the JVM will accelerate these gains. SaaS will allow a mixture of languages. And surely other language platforms will be Good Enough for many startups and for smaller apps at large companies.

But at the edge of the performance envelope, among memory managed languages, Java still seems to be a big winner, at least if the folks at Twitter are to be believed.

No it won't, JVM usage will just shift to wherever the need for massively scalable systems goes. If that domain shifts from in-house enterprise development to SaaS companies like Salesforce, the JVM will still be a top contender for those kinds of projects, wherever they're housed.

2) Sun did a great job marketing Java in the late 90s and early 2000s. So corporate managers felt safe adopting Java; it was the "in" thing. And as kls said, corporations have a lot of inertia. Why break something when it's working? (It's due to this mentality that some corporations still run VB6 and COBOL apps)

    Corporations don't understand IT

* Compatibility with installed base of existing code - Java is so prevalent on the server side that this is often a critical requirement

* Performance - The JVM is an amazing platform with excellent JIT compilation, very efficient garbage collection, great for concurrency etc.

* Huge library ecosystem, second to none. Most of the ecosystem is open source and if you choose your libraries and frameworks appropriately (i.e. anything but J2EE!) then you can be pretty much as agile as any other language.

* Major corporate backing (IBM, Oracle, Google, Red Hat). There's enough diversity in the supplier ecosystem that you don't need to worry about vendor lock-in too much (e.g. competing app servers).

* Java is more open and cross platform than the only credible alternative (.Net) - From a CIO perspective .Net is effectively vendor lock-in to a Microsoft stack.

* Great availability of "good enough" developers. There are also plenty of rockstars in the Java world if you look hard enough.

* Maintainable code. Java's relatively simple and concise syntax actually makes it quite easy to maintain with the medium-skill developers that most corporates have.

* It's not Java per se., but the innovation happening in the new JVM languages (especially Scala and Clojure) actually puts the JVM pretty right at the cutting edge of language development.

Note that a lot of the above reasons make Java a good choice for startup companies too, especially if you pick one of the new languages and go for "Java the platform" rather than "Java the language".

"Taking months/years to get something off the ground" has little to do with Java itself and mostly to do with corporate project lifecycles.

Probably a bit off topic, but PHP/Ruby/Python/Perl scale up much easier than Java scales down. And there's fewer large scale problems/apps than there are smaller scale stuff, so we see far more usage of PHP/etc in most day to day work.

Removes some uncertainty around planning maintenance & operational costs. Java developers are plentiful and framework training/certification programs are out there for the 'feel goods'.

Also... turns out, .NET is adopted for the above reasons as well.

I believe that we use VB6 and .NET because that's one of the two main platforms student learn (the other being Java), and programmers can be treated as interchangeable pieces. You're certain to receive thousands of applications for a job posting, and get outsourcing cheaply and easily.

Are the results good? I believe they mostly aren't, not because of a flaw in the platforms. And yes, change is sloow. There are too many stakeholders for anything.

I've heard of agile development with Java or java-likes, and .NET as well, it's not a platform thing.

I think Java right now is easily understandable by blue collars (not the code, but the architecture and the design part). It may not be the right choice, but big companies try to avoid the unknown and they tend to think that things they can understand (OO being an example) are better than the other options.

The rest of the ecosystem is pretty good.

I'm a bit confused, you have experience with Java, or you don't?