Cuckoo for Concurrency

4

A while back, I pointed to an article I wrote for JavaWorld: “Actors in Erlang”. That article was an intro to the hardware trends driving concurrency, Erlang, and actor concurrency in Erlang. Yesterday the follow-up, “Actors on the JVM” was published. Part 2 goes through various actor alternatives on the JVM such as Scala, GParallelizer in Groovy, and Java frameworks Jetlang, Actors Guild, ActorFoundry, and Kilim.

Between the time that part 2 was written and published, a new Java library called Actorom was released, done by the prolific open sourcerer Sergio Bossa. I also regret that I didn’t find time or space to fit in the FunctionalJava version of actors.

Also yesterday, Jonas Bonér posted his slides on alternative concurrency paradigms on the JVM. His slides cover actors but also Clojure’s STM + agents approach, and data flow concurrency. Very cool stuff.

If you’re interested in such stuff, I also do a concurrency link blog of stuff like this for a variety of languages.

Comments

4 Responses to “Cuckoo for Concurrency”
  1. Adam says:

    One of the features of Erlang is message passing between processes (and machines). Do any of the frameworks referenced in the article provide the same?

  2. Alex says:

    A good question, Adam. Scala has been clustered with Terracotta. Jetlang has been clustered with Terracotta.

    The Actorom library that’s not in the article has distributed support via Apache Mina.

  3. Sergio Bossa says:

    Yes, Actorom supports remote actors communication, with more and more features yet to come: feel free to give it a try and throw any feedback!

    Cheers,

    Sergio B.

  4. Jens Riboe says:

    I read both your JW articles this morning and couldn’t resist re-implementing the rock-paper-scissors application using a library I wrote many years ago that provides thread-method-invocation (TMI) in Java.

    I then wrote a blog post describing the result.

    TMI is not exactly the actors model, but closely related. My code illustrates how easy it is to design a concurrent Java program using message passing, without resorting to byte code instrumentation or another language.

    What do you think?