I read an article that says Scala handles concurrency better than Java.


...the scalability limitation is confined specifically to the Java programming language itself, but it is not a limitation of the Java platform as a whole...

The scalability issues with Java aren't a new revelation. In fact, plenty of work has been done to address these very issues, with two of the most successful projects being the programming languages named Scala and Clojure...

...Scala is finding ways around the problematic thread and locking paradigm of the Java language...

How is this possible? Doesn't Scala use Java's core libraries which brings all the threading and locking issues from Java to Scala?


Well, of course it does. And Java reuses all the infrastructure provided by the JVM, which was written in C, and it ultimately runs in machine code!

The point of enabling developers to let their applications scale is not to provide more raw power. Assembler already has all the power that your hardware allows, and no language can provide more. In fact, the entire point of higher-order languages is to restrict what programmers can do in them them. That sounds horrible, but the bottleneck in writing great, correct, efficient code is not the computation model. It is the brains of the people who have to understand the programs written for the machine. Experience has shown that we are not smart enough to understand the theoretically optimal solution of a complex computation problem; we would probably not even recognize it if we saw it.

In the concrete example, the article presumably means that Scala provides higher-level libraries and concepts that make it easier for developers to understand their problems from the perspective of concurrency, and so the end result is better and more scalable than coding directly in Java (or C, or Assembler) would have been. That doesn't contradict the fact that Scala runs entirely on top of a Java virtual machine. The JVM is a beautiful invention that allows all kinds of neat stuff to be written more easily than would be possible without it - including frameworks and libraries that make even more complex things easy. Amazing, isn't it?

  • 2
    Higher order languages do more than restrict. They enable abstractions as well -- assembler has all the power of the hardware, but it does little to let you abstract over it. And in this particular case, I'd say what Scala does is 50% restriction, 50% abstraction. – Daniel C. Sobral Jun 8 '12 at 3:38
  • 1
    @Daniel - I agree that abstractions are valuable but surely abstraction is just a form of restriction? In the sense of removing specific details of concrete instances and retaining only the general concept? Wikipedia puts it like this: "Abstractions may be formed by reducing the information content of a concept or an observable phenomenon" – mikera Sep 19 '12 at 13:17

It's a matter of library support. Java uses the low level Thread construct to represent concurrency (this is like the assembly language of the concurrency world). There are lots of libraries and techniques you can use to build scalable solutions on top of these such as using the support provided by the java.util.concurrent package and following Brian's Goetz's techniques in his Java Concurrency in Practice book. Scala helped introduce things like the Akka framework (also usable by Java now) which bake in some of these better practices and library support. That's not to say that Java the language couldn't catch up (parallel collections etc), as Kilian states, it all runs on the JVM and therefore the JMM.

Also, Java's objects are also mutable by default and it requires some non trivial knowledge to make them effectively immutable. Scala reputedly makes it easier to create immutable objects


Doesn't Scala use Java's core libraries which brings all the threading and locking issues from Java to Scala?

Well, yes, and if you do locking in Scala you'll face the same issues. The point, however, is that you are not supposed to, as Scala provides you with abstractions that handle this problem in a safer manner.

Now, Scala does two things that really helps. One of them is the actor model, which can be thought of as a concurrency pattern, provided by Scala as a library. If you are a Java programmer, I suggest you go to Akka site and look at their Java stuff. This is the library that will replace Scala's current actor library, and you can use it from Java.

The second thing that Scala does that helps is using immutable data structures. There's nothing preventing Java from using immutable data structures -- String, for one, is itself immutable! Immutable data structures do not suffer from concurrency problems since threads can't change them.

There are other things that add to these, to make up full solutions, such as agents and stm (both available from Akka), or latches (from Java).

Now, the two things above can be done in Java, as I said myself. You can use Akka in Java, and you can write immutable data structures in Java (or use from libraries that provide them). However, Java makes it a pain to use this stuff, because it supports neither higher order types, nor closures and first-class functions.

So, while you can do it, programmers usually won't because, in Java, writing such code is very verbose (I mean, much more so than the standard for Java).


The main thought of the referenced article is:

the scalability limitation is confined specifically to the Java programming language itself, but it is not a limitation of the Java platform as a whole. In fact, when programs are written to properly take advantage of the underlying Java platform, linear scalability isn't an issue.

If massive scalability is what you need, you can always take advantage of peripheral JVM languages like Scala and Clojure

I cannot agree with this. Using JVM languages like Scala implies:

  1. using specific runtime support. This support can well be accessed from Java programs directly.

  2. specific syntax, allowing concise expressions to make access to runtime support easy and less error-prone. This is true, and writing in pure Java is more verbose and requires more discipline, but the gap is not that dramatic.

In short, Scala handles concurrency better than Java because of using Actor model. Actor model can well be employed in Java. There are several actor libraries for Java, including Akka (used by Scala), so switching to Scala is not an imperative.

Using Actor model via pure Java has its own advantages:

  • easier debugging
  • possibility to customize the actor library used. This is especially true when the library is compact and thus understandable, like this one of mine: df4j

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.