I would say that the java language itself has nothing to do with scalability (Ron’s comments about garbage collection were outdated and haven’t been seen by me in post 1.4 JVMS on multi-gigabyte production clusters) I do agree that the J2EE server mindset guides people into design patterns that are at a medium-level of opportunity for scalability.

However, almost everyone accepts that old-school J2EE is dead and the unstoppable trend of inversion of control has caused a dismantling of the once immutable bundle known as “the server”

Specific to scalability, this destruction of the monolithic server has lead to wider usage of such toolkits as: jgroups, ehcache and terracotta. Those toolkits encourage average architects to use the sophisticated networking design patterns formerly applied only by the highly experienced engineers who developed clustered server products. Today, jgroups is actually used internally by Jboss to implement their clustering model.

I would say that the true force pushing scalability is the java community itself. Perhaps we have to thank Sun for fostering that community even though they did it for their own marketing purposes. In any case, java is merely a convenient and commonly spoken language that allows for the formation of a global community. Like it or not, Sun’s tight control of the java spec forces the community to stop debating the language internals and start debating sophisticated design patterns such as those that promote scalability.

As a result, huge response latency times effectively puts a limit on available memory, which in turn puts a limit on ultimate Java application scalability when compared to C++ (of course, with C++ you have to be careful to give the memory back). In fact, the Real Time Java API extensions were developed as a way of addressing this problem (creating what is in effect thread local heaps) but this requires code modification … and if done wrong, can actually slow down overall performance.

One alternative (from Azul Systems) transparently redeploys unmodified Java applications to what is effectively a Java Compute Appliance, allowing them to scale to hundreds of Gbytes of memory with negligible GC pauses … but this is only possible because Azul exploits some special hardware instructions in their box. Another is to horizontally scale out an application (all stock trades A-C go to system #1, D-F go to system #2, etc.) so memory requirements for any one instance are under control. But this results in server sprawl, crashing instances when peak loading spikes (stock B split creating lots of activity) involved synchronization on multi-stock trades, special factoring of the data set into parallel instance caches, etc.

Scaling Java applications past a certain point ain’t easy.

developer liquidity is a major factor as well. you have to look at the marketplace and grab a toolset/language/framework that lots of people know, so your env. can evolve with the ecosystem in which it lives.

I often find folks talking about insert-language-here and “scale” doing so just as a conversational starting point rather than a definitive statement.

Java – however – is not just a language, it’s also the huge collection of frameworks. “Java” is the equivalent of both Ruby and Rails. And while neither the language nor the frameworks are perfect, they have been used to build extremely scalable systems for about a decade now. People call Java scalable not because it’s better suitable for building scalable systems, but because how to build scalable systems with it is well understood and the components you need to do so are widely available. Not only are those components widely available, they are available from multiple vendors — some free, some commercial — so you’re never locked in, an aspect that’s extremely valuable when producing commercial software.

I totally believe that you can build equally scalable applications using Ruby & Rails, but how to do that is not widely understood. Even if you can hire someone who understands it, you can’t replace the person if he leaves.