FunctionSource, Your Source for Developer News

Node.js gets most of the server-side JavaScript love, but for those folks that are limited to JVM solutions, RingoJS provides an interesting alternative. It’s an evolution of Helma, one of the oldest server JS solutions around; it leverages Rhino to provide a server JS environment that can be cleanly deployed in a WAR/EAR file for those stuck in enterprise hel^H^H^H^H land.

About two weeks ago, Hannes Wallnöfer, a Ringo committer, made an interesting post about his ten years or so of experience working with concurrent JavaScript. Whereas Brendan Eich famously declared that threads and JavaScript have no business going out together for a night on the town, Hannes maintains that “threads are not evil” and that with the right coding style, working with JavaScript threads can be a “piece of cake”.

So what is the “right” coding style, you may ask? Hannes maintains that:

1. Threads aren’t evil; shared state is.
2. Writing functional-style JS to avoid shared state is straight-forward, and Ringo helps by disallowing implicit global state.

He then points out that closures are all about shared state and when you use them, Ringo attempts to make life easier by:

1. Immediately updating the values of shared state across threads by leveraging Java’s volatile keyword
2. Introducing an equivalent to Java’s synchronized keyword

For a blog post that started out admitting that concurrent development using manual locking is hard, I was a bit surprised to see Hannes delve into improved manual locking mechanisms by the end of the post, but he does end on a high note pointing out the thread-safe data structures that are available to Ringo developers via java.util.concurrent and Clojure, both of which are accessible in Ringo.

Hannes concludes by suggesting that in the future, he’ll look at providing a type of closure in Ringo that detaches itself from its parent scope in an attempt to avoid shared state whilst preserving the convenience of easy, in-line callbacks.