[nupark2]

Most of these answers don't seem to be written by anyone actually involved in "enterprise" development.

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.

[ryandvm]

Nah. Those are the reasons that an organization would like to list for using Java. But "kls" nailed it above. It's mainly inertia and labor availability at this point.

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.

[nupark2]

Nah. Those are the reasons that an organization would like to list for using Java. But "kls" nailed it above. It's mainly inertia and labor availability at this point.

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

[mseebach]

If anything, they are reasons that enterprises aren't in any kind of hurry to abandon Java.

[kls]

Right which was my point above in setting the history of how we got here and why no one is really interested in leaving. The history is very important to how Java became dominate and created the top reasons, which I would content are inertia and labor pool. The reasons bullet pointed above are why no one is in a hurry to move on, it does what it is supposed to do and the enterprise is happy with it. Until the cost/benefit is blown away, they will continue to be happy with it.

[vannevar]

It's mainly inertia and labor availability at this point.

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.

[brlewis]

I'm excitedly curious about when this bullet point has come up as a selling point for the JVM in "enterprise" development:

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

[theshadow]

Not all JVM languages are created equal (JRuby and to a lesser extent Clojure) are no way near Java in terms of performance on the JVM

[brlewis]

Kawa Scheme is near Java: http://per.bothner.com/blog/2010/Kawa-in-shootout/

[Mikera]

This is spot on. One point to add though: Java is remarkably maintainable due to the high commitment to backward compatibility, great tools, availability of standard skills and the relatively simple syntax ("conciseness considered harmful"). This shouldn't be underestimated in an enterprise setting....