Multiprocessor systems have gone from being rare and expensive to being ubiquitous. As the hardware reality changes, so do the programs we want to write and so must the platform and libraries we rely on. In Java SE 7, the java.util.concurent package will grow to address the need to exploit finer-grained concurrency, in the form of the fork-join framework.
Brian Goetz is the author of over 75 articles on software development, and the book, Java Concurrency In Practice. He serves on the JCP Expert Groups and is a Sr. Staff Engineer at Sun Microsystems.
QCon is a conference that is organized by the community, for the community.The result is a high quality conference experience where a tremendous amount of attention and investment has gone into having the best content on the most important topics presented by the leaders in our community. QCon is designed with the technical depth and enterprise focus of interest to technical team leads, architects, and project managers.
Excellent overview of the forkjoin framework provided by Brian.
I particularly liked when he mentioned that threads are expensive, as if this was basic truth, instead of a consequence of various characteristics of Java.
Now, the library is nice -- actually, very good, and if I hadn't read about it before and the presentation was a bit more honest about the very limited scope of what they were doing, it would be a great presentation.
For those still left looking for effective massive concurrency, it seems Erlang and the like are still it.
First, if Java "sucks as a language for massive concurrency", it's because all mainstream languages, which are largely imperative and OO, "suck for massive concurrency".
I'm not sure what you mean when you say the approach described is "ad hoc", or that anybody claimed that it was original. In fact the speaker alluded to previous approaches implemented in other languages at the beginning of the talk. My reservation is that this is not applicable to "everyday problems" but I believe the point the speaker is trying to make is that this WILL be the everyday problem as we face the challenge of massively parallel hardware.
The fact that threads are expensive is a basic truth (they are more expensive than not using threads). This truth stems from operating system implementation, and is possibly worsened by language implementation. If you could say anything about Java, it is not that it does not have a superb VM. Java's VM is best in class, has had massive engineering years poured into it by some really brilliant engineers, and beats the pants of other languages/VMs that could be considered alternatives to Java/JVM: Ruby, Python (both of which have been plagued by infamous "global interpreter locks"), and probably anything else out there.
Perhaps you have some antiquated ideas about Java from 1997? Let's say the Java runtime was perfect, there is still thread overhead at the OS level. This is not specific to Java. All languages that use threads (including natively compiled languages) have to deal with this. There are of course many alternatives available: fibers, events, async IO, etc. But your claim seems to be that threads are expensive specifically due to characteristics of Java, not that other approaches should be used.
Of course if you are looking for "massive concurrency" look at Erlang. Look at a lot of things. Erlang is conspicuously NON-mainstream, so Erlang developers are obviously NOT the target of this talk. If you have been writing massively concurrent Erlang for the last 10 years, well, I guess you get a pat on the back, but you are certainly the exception and I don't get what your beef is with the Java community building new libraries for themselves.
By the way there are languages that suck less for concurrency on the JVM, including Clojure and (gasp) Erjang.