There's a lot that can be said about Oracle's stewardship of Java, what it's like and how it should improve; it's a very important conversation. But the tone of your comment (and some of its child comments) seem to take the discussion in a misinformed direction. I don't know how much of the world's important server-side software is written in Java (or runs on the JVM), but I wouldn't be surprised if it's around 80%. The fact of the matter is that aside from small-to-medium startups' servers, the world's server-side software is mostly Java. Almost all non-embedded, large defense software is Java; almost all banking software is Java; Facebook, Twitter, LinkedIn and Google are mostly Java/JVM shops (when it comes to their infrastructure software).
Saying "I'm not using anything owned by Oracle" is something most serious server-side developers just can't say, because, frankly, there's little choice. If you require high-performance, multi-million-LOC software developed by a large team, you would be quite foolish to choose anything but the JVM. So we should certainly discuss Oracle's behavior, but pretending that we can avoid Oracle software like it was a specific linux distribution is a misrepresentation of reality.
You are correct that the JVM is ubiquitous in server software but not nearly as much as you assume and there has been a shift away from it in recent years for reasons having nothing to do with Oracle etc. I've been designing high-performance server engines since the 1990s and have watched the architectures and tool chains evolve.
Five years ago most new server engine development was done on the JVM. Since then there has been a shift toward new development being done in C++ such that the vast majority of new server engines I know about are being developed in C++ (mostly C++11) across a diverse range of companies. The reasons are practical and reflect the evolution of hardware.
The short version is that on current hardware C++ is much more efficient, both in terms of throughput per core and can achieve integer factor improvements in absolute performance relative to the JVM. Most of the differences are boil down to two things. First, server performance tends to be bound by memory performance and the JVM is quite a bit worse than what is easily achievable in C++. Second, an optimal high-performance server engine design in C++ is difficult to express within the JVM so basic design of the engine kernel tends to be less efficient as well.
In large-scale systems, that starts to add up in terms of power and hardware consumption and companies are more sensitive to this than they used to be. C++ currently offers significantly better characteristics and using less hardware to do it.
I thought I knew most of what is hot and fresh on the software development front, but I've never heard of any "server engines." Mind explaining what it is? Virtualization containers perhaps?
A "server engine" (usually called a kernel actually) is like a userspace operating system kernel that is purpose-built for a class of server workloads and attempts to optimally manage system resources for that workload. The server application is built on top of that kernel. When people refer to e.g. "database kernels", this is what they are referring to. It reimplements the operating system resource management services through the OS APIs.
Writing an excellent server kernel requires a high level of technical ability and quite a bit of low-level code since you have to reimplement most of the operating system resource management services most developers take for granted. Few pieces of open source server software are built on userspace kernels and the ones that do like PostgreSQL are (currently) only partial kernels that still rely on the OS to do significant things a full kernel would reimplement. A properly designed database kernel, for example, is at least 100k LoC of low-level C/C++ and that is before you actually write the server application that sits on top of it. I've designed and written kernels for both database engines and network engines, it is not trivial.
So why would you want to go through all this effort instead of writing to the standard POSIX APIs directly? Because performance and scalability. For example, a well-designed disk buffer and scheduler for a database kernel can easily triple the I/O throughput possible with a highly tuned POSIX implementation. A lot of locking and blocking, both explicit and implicit in the OS, become unnecessary. Certain kinds of distributed system problems become easier to solve because you can adaptively schedule data flows at a fine-grained level. One of the reasons Oracle and DB2 scale so well and get such high throughput is that they are built on highly optimized userspace kernels.
Virtualization actually degrades the performance of high-performance server systems in part because the hypervisor acts as a primitive operating system underneath the operating system the server kernel can see. This does not impact non-kernel based servers as much.
In the really large server-side systems we're talking about here (banks, defense, etc.) both developer productivity and maximum speed rank way, way below other factors, such as having long-lived processes.
Java's not a clusterfuck? I'll take the clusterfuck that's not controlled by a creepy asshole who thinks the NSA is essential and says stupid shit like "Who's ever heard of government misusing information?"
I agree with you, but as I can choose the software I create and with what I'm not very interested in working with Oracle stuff.
I worked with Java since 0.1 in the enterprise world for over 10 years and with Clojure & Scala I would continue with it, but I don't trust Oracle to do the right thing in releasing source at the same pace or at all for some critical perf/scaling features and I tend to think thats wrong.
How does OpenJDK handle serverside compared to the Oracle binaries these days?
Actually, most companies that aren't Google (finance, government, military, enterprise) realized that simply sticking with Oracle is even a better move. I don't know if you know this, but Oracle is making more money (profit) than Google (Oracle is also a much larger company than Google). They wouldn't be doing that if people were staying away from them. Lawsuit aside, even Google itself (and Facebook, and Twitter) runs most/much of its software on Oracle technology, so I guess they're doing something right. It's just that HN is skewed in favor of smaller-scale software. When you're in the major league, Java is often the only smart option.
there may be more reasons other than technical that large businesses run on Oracle (database).
The amount of paid "consultants" that oracle pushes thru to make their sale, plus their tactic of charging what you can afford to pay, as well as the "can't get fired for buying IBM" mentality of large IT organizations means that oracle has a distinct advantage over any small competitor.
Not that oracle's tech isn't good, but there are comparable alternatives, but they are only comparable in the technical aspect, not in the (strongarm) sales aspect.
.NET is a fine alternative in 80% of the use cases. Honestly, in half of the projects I see coming through, the only reason java is a requirement is because everything else is already in java; the only hang up is DB2/MSSQL/Oracle drivers.
.NET is never a good option to Java. The CLR suffers the same performance issues as the JVM and as noted in the thread above people are starting to migrate back to C++ as a result and yet .NET has the further restriction that it only runs on Microsoft systems. So with .NET I get the disadvantages of Java combined with the restriction of not being to migrate to other platforms. That's not a good deal for the enterprise.
The world is in corporate hands, but Oracle and the JVM are far from being the worst of it. At least all Oracle wants is your money, unlike a younger kind of mega-corporations that will give you services free of charge only to hold your most secret information – e-mail, photos, current location, documents and more. Oracle can be infuriating, but it's not scary because it can be easily understood. What companies like Google want, well that's far scarier. It's also a completely different discussion. :)
True, true, and to hell with it I even like the JVM. I just don't differentiate google or facebook from oracle, they're equally "corporatish" for me :)
Saying "I'm not using anything owned by Oracle" is something most serious server-side developers just can't say, because, frankly, there's little choice. If you require high-performance, multi-million-LOC software developed by a large team, you would be quite foolish to choose anything but the JVM. So we should certainly discuss Oracle's behavior, but pretending that we can avoid Oracle software like it was a specific linux distribution is a misrepresentation of reality.