Compare java and scala in MultiThread aspect [closed]

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance. Closed 11 years ago.

I just hear and see people saying scala is designed for MultiThread though it's actually for general purpose.

And it claims "The thing is that while you can make classes thread-safe in Java (if you know what you're doing ), Scala makes it easy and natural to do."

And indeed AKKA and Lift is written in scala.(actually java and scala)

But java also did improves in this aspect with the new package of java.util.concurrent. So why didn't AKKA and Lift born in JAVA?

Maybe you will say scala makes java looks like C. :-)

Anyone can tell more insight or deeper thoughts on this?

I know the fact that it is possible to mix JAVA and scala. Scala is able to call seamlessly into Java code. So what java have,so does scala.

But what scala really improves that java haven't done yet regardless of different grammers?

Only some design like Actors/Agents or something else? (note Actors/Agents are cannot solve all the problem in MultiThread.)

Or does scala compiler and adopting some functional language grammer really matters or helps more than in java?

I heard some news that scala is going to be able to adopt XText. To be able to leverage XText to write thread logic, not sure if this is true or not.

Scala looks like a mixture of languages and using this approach makes it more extensible to solve problems in this aspect?

UPDATE

Thanks for your excellent answers from different angles. I think they are all very good. No matter what side you are standing.

EDIT

Topic below (in SO one year ago) was 开发者_Python百科asking about the similiar thing. The "constructive" conclusion is quite similiar. But this time ,some new points are coming out probably the way I am asking is a bit different. Just FYI.

Related:

• What advantages does Scala have over Java for concurrent programming?

• Java Concurrency: CAS vs Locking

• Difference in MultiThread aspect between Java and C/C++

• Pitfalls/Disadvantages of Functional Programming

Actually I am very interested in some one can answer this question in some brand new angle which could enlighten my mind , provide some idea unknown before.

But it's closed due to not constructiveness. :-)

---

I am not really an expert in this, but Scala is a (partly at least) a functional programming language while Java is not (it is imperative). One feature of functional programming is that it avoids (in a 'natural' way) side-effects.

Thread-safety on the other hand is pretty much about avoiding side-effects (i.e. different threads modifying same objects/parts of memory/other resources at the same time).

---

As it is today, I find Scala much worse than Java with respect to working with multiple threads.

The language specification doesn't define some really important things, that you would rely on, to make thread-safe code.

For instance, you should know that final instance fields are very special when working with multiple threads. They are guaranteed to have their initial value visible to all threads after the constructor has completed, even if the object is published with race conditions.

Scala makes no guarantees that a val will be compiled to a final field. It is usually the case, but since the specs don't state it clearly, you cannot take it for granted. Therefore, either you write boilerplate synchronization code that wouldn't exist in Java, or you write code that is not guaranteed thread-safe (and hope for the compiler to continue mapping your vals to final fields).

---

I'd say it not so much a matter of the actual language, but more about applying principles which ease concurrent programming, e.g. share nothing, message passing, immutable objects, side-effect free functions, etc. Scala is not a FP language in it's strictest sense, but it delivers access to functional programming techniques.

Abstractions like Actors/Reactors, which are part of the framework (not language), completely free the developer to handle threads and critical section synchronization directly. What's more: Since 2.9.x, parallel collections are directly included in the library.