Peter Williams addresses the threading issues raised by Tim Bray here - I commented on that awhile back, here. I like Peter's take:

The threading issue is the one that interests me the most. I think that Mr. Bray is right that hardware threading is quickly becoming an important issue. In the near future most machines will support significant levels of true, hardware level, concurrency. But I think the shared memory native threading model that Java has is completely untenable.

Even vm (green) threads, which are well understood and have nice uniform semantics are difficult to use correctly. Once you throw in the vagaries of native threads you have morass of complexity that is practically unbearable. Worst of all, the usefulness of most of the techniques we have to help manage software quality, like automated unit tests and continuous integration, are inversely proportional to the number of threads in the application.

The thing you want to consider is which resource is more expensive - the hardware or the people-ware. Computers and networking equipment are only getting cheaper. People, on the other hand, are not having an easier time grokking multi-threaded code as time goes by. Which problem is easier to solve? Running more processes on the multiple CPUs/cores present, or getting people to accurately and safely thread applications within a single memory space?

The most important thing to keep in mind here is that, in the long run, it is always better (read: cheaper) to use extra computing resources to make problems more tractable for the humans in the system. For example, we have garbage collectors because it is cheaper to buy a slightly more powerful computer than to have you developer waste time managing their own memory. I am not sure what the best solution to highly concurrent hardware is but I am quite positive it is not Java style threading. My gut tells me that none of the approaches I know for apparent concurrency are going to work well for a highly concurrent application on highly concurrent hardware. If that is the case we will see something new and different as soon as the cool hardware gets into circulation.

That kind of work is one of my higher level priorities for Smalltalk as we move into the future. Java's "answer" is a complete non-answer, as far as I'm concerned.