Comments on: Want Erlang concurrency but are stuck with Java: 4 Alternatives (+1)

By: actor model concurrency | Javouhey's Blog

actor model concurrency | Javouhey's Blog — Sat, 15 Jan 2011 13:54:32 +0000

[...] actor frameworks for java [...]

By: Bjorn Borg

Bjorn Borg — Wed, 04 Aug 2010 21:02:15 +0000

Kilim in my judgment is an attempt to misuse the purposes of a University in coming up with an offering to gain appeal with Java corporate world in the guise of academic research work. Hundreds of successful Java frameworks have been written during week-ends by great people through open source initiatives. Kilim can come no way close to them in terms of acceptance from the Java community. But unlike Kilim, none of them have got a PhD because they were willing to play by the moral rules of the game than go for fringe gains. You don’t need the paraphernalia of a University (professors, library, state grants …) to write a Java framework eh! Hope Universities see through this, if not they will be rendered inconsequential. For heaven’s sake, may Universities focus only on works which have larger impact on the society, bring real futuristic technologies that would make our generation proud!

By: Bjorn Borg

Bjorn Borg — Wed, 04 Aug 2010 21:01:42 +0000

For some reason, actor model does not seem like a natural extension to Java. I am no James Gosling to say whether Java is meant to do this or not. Perhaps should we shift the blame on to the frameworks which have made actor model like an after-thought on Java? These weaving strategy implementations like Kilim, ActorFoundry, Actors Guild etc… have to take some blame for making actor models look very unnatural to Java development – putting a kink in every development step and development tool. The leap of faith with actor models may perhaps never happen until it is made a part of Java platform itself (like how actors implementation is provided as part of the Scala standard library). For now, for die-hards Java nerds, I would suggest that among Java alternatives, Jetlang is the best because it provides a consistent model that does not feel misplaced or unnatural in the context of Java.

By: stephan

stephan — Wed, 07 Jan 2009 06:29:35 +0000

@Alex: Would like too, currently not in a position to go to conferences sadly.

I wish you good luck with your talk, the topic seems to catch on. It’s a long way though before actor concurrency knowledge is spread enough.

By: Alex Miller

Alex Miller — Tue, 06 Jan 2009 22:08:14 +0000

If you’re interested in this topic and attending CodeMash this week, I’m giving a talk on Actor Concurrency that will cover Erlang, Scala, Kilim and possibly some of the others.

By: Tim Jansen

Tim Jansen — Tue, 06 Jan 2009 20:26:05 +0000

@Steve: I am not sure what you mean by ‘lightweight’ threads, but Actors Guild goes to great length to keep the number of threads down – there is no 1:1 mapping between actors and threads.

AG manages all actors which have work, and the number of messages that could be processed simultaneously in the actor. In AG, an actor can be stateless or have stateless messages, or even have ‘multi-threaded’ messages without synchronization guarantees. In those cases, an actor can process more than one thread at a time.
Then, AG calculates the right number of worker threads to process the messages. The exact numberis limited by configuration and the system’s number of cores, as well as the type of message (a message doing IO or even waiting for an external event such as a TCP connection needs less CPU time than a message that computes something).

By: stephan

stephan — Tue, 06 Jan 2009 06:00:24 +0000

@Steve: Could you be more precise? Both Kilim and Scala seem to perform as good as Erlang does? What am I missing?

I think it’s not a threads problem but a scheduler problem.

@MumboJumbo: I though Clojure had STM for concurrency, not message passing?

By: Mumbojumbo

Mumbojumbo — Mon, 05 Jan 2009 22:47:48 +0000

Clojure anyone? (www.clojure.org) Runs on the JVM and interops with Java.

By: Steve Dekorte

Steve Dekorte — Mon, 05 Jan 2009 22:03:35 +0000

Just a note: for “erlang style concurrency” I’m guessing you mean both actors and being able to support a high level of concurrency. For the later you’ll need lightweight threads, so any actor concurrency based on OS threads won’t be sufficient.

By: stephan

stephan — Mon, 05 Jan 2009 15:36:59 +0000

@Robert: “[...] close integration/interaction between processes, asynchronous messages, immutability and error handling which is the real strength of Erlang.”

Yes, could be the case.

1.) “asynchronous messages” I’d say the frameworks can handle this. The annotation based ones are not as nice as using “!” but close to me.

2.) “immutability” Depends on your style, lots of programmers in Java already write immutable code (no getters, excessive use of final etc.), but it’s better if a language supports this – as I’ve said before, all declarations in Java should be final

http://www.codemonkeyism.com/archives/2008/04/22/all-variables-in-java-must-be-final/

3.) “error handling” Currently you’re out of lack for Java and I would use Scala OTP when using the JVM for that.

http://jonasboner.com/2008/12/11/real-world-scala-fault-tolerant-concurrent-asynchronous-components/

By: Apocalisp

Apocalisp — Mon, 05 Jan 2009 15:31:36 +0000

Don’t forget RetroWeaver. It lets you use Java 5 language features, and you can compile the 1.5 libraries with it so that they work on 1.4.

By: Rajesh Karmani

Rajesh Karmani — Mon, 05 Jan 2009 15:16:34 +0000

One clarification: ActorFoundry just uses Kilim’s weaver and therefore is not built on top of Kilim. It has its own run-time that supports distributed execution of actors, migration, fairness and allows safe message-passing for any complex Serializable object. In terms of model, it abstracts away the mailbox, the control. All these are lacking in Kilim and Scala currently.

By: Robert Virding

Robert Virding — Mon, 05 Jan 2009 15:09:48 +0000

I think much of this misses the point: the problem is not to make an actors-like message package (done a few others myself) or immutability (which Java doesn’t have), but it is the close integration/interaction between processes, asynchronous messages, immutability and error handling which is the real strength of Erlang. Things will go wrong, processes will crash and the rest of the system must be able to survive and clean-up afterwards and continue functioning.

You don’t use an actors based model to help on multicores but because it is the best paradigm for many applications. The multicores and distribution you get for free.

Although I hate to quote myself I can’t help it:

http://rvirding.blogspot.com/2008/01/virdings-first-rule-of-programming.html

By: stephan

stephan — Mon, 05 Jan 2009 14:45:40 +0000

@John: From the post: “And if you’re only stuck to the Java VM but not the Java language, you could go for Scala and gain some functional programming capabilities on top.”

By: John Kemp

John Kemp — Mon, 05 Jan 2009 14:18:21 +0000

Why not just use Scala (http://scala-lang.org) Actors?