Hacker News new | past | comments | ask | show | jobs | submit login

Doing concurrency right is very, very easy in just plain Java. ExecutorService is all you need, it's even 100% FP as long as you remap "anonymous class with 1 method" to "lambda" in your head.



Executors solve a specific concurrency problem (i.e. futures), but they're not a general solution for cross-thread communication.


Well, then there's BlockingQueues as noted above. Callables, Runnables and BlockingQueues are a great setup for CSP-style concurrency.


That's still far from a general solution.

Let's consider an example. One of the classic concurrency problems is managing a bank transfer. In this problem it's important that the debit and credit operations happen atomically. If one operation fails, then both operations should fail.

In Clojure, we'd write:

    (defn transfer [from to amount]
      (dosync
        (alter from - amount)
        (alter to + amount)))
How would you write the same thing in Java?

A lot of the problems with dealing with concurrency are in communication between threads. BlockingQueues and Executors only deal with a small subset of concurrency problems, and blocked threads are a fairly inefficient use of resources compared to async solutions.


I have probebly not done much Java Concurrency. Sure you can simulate CSP with Blocking Queues but since you bind real threads you will run into tons of problems.

Why dont we ask Brian Goetz a Java Language Architect how "easy" it is, read his book [1] and then lets talk again how easy it is.

[1] http://www.amazon.com/Java-Concurrency-Practice-Brian-Goetz/...




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: