Scala does it better? :P

+Casper Casper Alternative solution, interesting!

are you looking for some kind of solution to a problem? or are you just reading out of interest?

I was tumbled during a job interview asking if I know about CountDownLatch class, so I went through Java Concurrency tutorials, books looking for answers afterward.

Basically, from my understanding, if you want to get concurrency working correctly in Java, you have to depend on java.util.concurrent package. Admittedly it's powerful, but looking the boilerplate codes and plumbing work have to carry on clumsily, just don't feel things are right.

So I'd like to discuss whether there is a better solution in Java.

Scala, if you have the choice, is certainly a better choice replacing Java especially in backend in concurrency. Like ecstasy for Java developers, Scala is moving developers' focus away from the meat of the problem, and leaving low-level details of concurrent programming to a framework to solve.

It might take some work to massage Scala code into an EE context (depending on what your client will let you get away with, or how nicely the technology will let you), but it might let you get away with some really nice tight code.

I haven't learned Scala yet, but have heard positive things about how it handles concurrency.

the java.util.concurrent package is great :)

The important thing regardless of the language is to design your application so that the threads have little to no shared state. Where there is a need for shared state you should create interfaces that manage the concurrency for you to keep all the tricky code in one spot. There is increased challenge in a J2EE environment as you are limited to what it offers in regard to thread creation and it doesn't offer much between hosts.

if you can do it without shared state, then it becomes a lot easier :D.