Hacker News Reader

Comment by bsder | Hacker News Reader

They're in Java and writing locks and threads. Sigh.

java.util.concurrent is probably the single best concurrency library I have ever used. Bar none.

When I'm writing in Java, and I find myself writing a lock, my first reaction now is: "This is okay for exploration, but which data structure from java.util.concurrent am I going to have swap in here when it's all done. And can I do it now and save myself a lot of grief."

It only took me 7+ years to come to this realization. Apparently I'm a slow learner. :(

View on HN

My small brush with this: back in the summer of 1990, I did a summer internship with Doug Lea who led the JSR 166 group that led to java.util.concurrent. My work was on a concurrency library for a parallel computer called the Encore Multimax

> summer of 1990

some thread corrupted this date

The main problem with Java is that you rely heavily on libraries and frameworks which may or may not enable you to apply a desired pattern.

Recent example: I am using Tomcat as a servlet engine. For dependency injection I am using JNDI. Tomcat can be configured to call a provided ObjectFactory to generate JNDI objects when they are requested. The environment I am using allows for some kind of blue-green deployment, I can switch between different fired up virtual machines transparently to users. I use this when upgrading. My provided Objectfactory logs when objects are created (some of them should be strictly singletons). Sometimes the logs indicated that multiple objects where created after switching to the newly updated machine. This was due to a high load on the system in which multiple threads where busy with incoming requests simultaneously. Neither the language library nor Tomcat has any safeguards in place (synchronization of any sort) although JNDI and in particular Tomcat supports singleton creation. I had to resort to statically creating the required instances at loading the Objectfactory, a pattern I dislike with a passion (you can't swap the implementation during runtime which can be annyoing in any long-running environment).

To be fair, that's more an issue of using a framework than anything to do with Java.

> "This is okay for exploration, but which data structure from java.util.concurrent am I going to have swap in here when it's all done.

That just doesn't work for most concurrent code. Often you have dependencies between data structures or other operations intervening. Most of the time it isn't a single structure, but a group of semantic operations across the program.

They're using Java instead of Clojure. Sigh.

I'm saying this as a massive clojure fanboy: java.util.concurrent is an amazing set of concurrency utilities and is the building block for many of clojure's concurrency features. It's definitely worth knowing when writing performant java AND clojure (you can wrap the little bit you need so you don't have to scatter java interop all over your codebase). Sometimes a (swap! atom fn) doesn't cut it.

Yeah, because some of the best concurrency primitives in the world aren't quite "what teh cool kids are doin'"

Reply on news.ycombinator.com