[Slashed]

I'm not very familiar with Clojure. On the first glance it looks like Clojure has a good concurrency system. I know many people are talking about Actors(like in Erlang) these days, but from my experience with Scala Actors, they're not very suitable to solve some problems(like when you need a very good performance). Even though Scala makes your life easier to work with native Java concurrency, it's definitely a good reason to have a deeper look at Clojure. Thanks for the info!

Edit: Is there an 'easy' way to create OSGi bundles with Clojure, maybe some sort of Maven plugin?

[tmountain]

Clojure has a few different concurrency mechanisms. Agents are useful for asynchronous manipulation of mutable state while refs allow for coordinated synchronous changes. Atoms allow uncoordinated synchronous access to state while vars act as mutable storage locations on a per thread basis.

Between these, you get four different strategies for dealing with concurrency. Depending on your problem, you can choose the most efficient mechanism. Rather than shoehorning you into a particular strategy, Clojure gives a you a toolbox for dealing with concurrency and lets you chose what makes the most sense.

[dkersten]

You forgot one: if, for some reason, none of the four mentioned concurrency strategies suit your needs, you can fall back to Javas monitor-based threading model. I don't see why one would want to, but I'm sure there are situations when this actually is the most appropriate mechanism.

[tayssir]

And a possible future feature is something like statically-checked locking, where order-of-acquisition issues are dealt with.

[mike_organon]

Actors for Clojure has been mentioned as a future feature, but this would be for remote procs. Clojure has Agents for local async state changes, but these are only used when you need that feature, not ubiquitously. You should ask on on the mailing list - people have worked with osgi and maven.