Parallelism and Abstraction in Java

Here's an interesting parallel programming interview with Intel's Paul Guermonprez covering threads, JSR166y, and Hadoop. I particularly enjoyed the Hadoop discussion at the end.

The discussion focused on efforts to separate Java programming from the nitty gritty details of threads. This separation allows a greater number of developers to successfully program for parallel environment by removing focus on the technical details, and thus reducing the knowledge required to write the code. There's also some coverage of the benefits of the higher level of abstraction of functional programming and how the functional programming style is being incorporated into the Java concurrency model. The text has this:

The future will be functional programming or won't be at all.

Intellectually, I applaud these efforts. Emotionally, I feel some loss.

My first introduction to threads was in a systems programming class, using the C language and Pthreads library. Pthreads blew my mind, or maybe it was lack of quality in the lectures. Either way, determined not to be defeated by Pthreads, I went out and bought a stack of books on Pthreads and threads in general and set out to wrap my mind around threads. It worked, but along the way, I learned that I loved the challenge and so I embraced concurrency and parallelism with much enthusiasm. This knowledge that I've accumulated will always be of great value, but as I move toward programming threads at further and further abstractions, I'll lose that close connection to the internals, and I'm a little saddened by that.

Dependency Injection and Inversion of Control

I've been reading quite a few blog posts on dependency injection recently. I don't know why that's suddenly the topic to write about since it's been around for quite a while. I don't have any brilliant new revelations to offer, but just maybe a few thoughts in response to a blog post I read by a Jordan Zimmerman, "Dependency Injection Makes Code Unintelligible"[1].

First, a couple of quick definitions from Wikipedia:

"Inversion of Control, or IoC, is an abstract principle describing an aspect of some software architecture designs in which the flow of control of a system is inverted in comparison to the traditional architecture of software libraries."[2]

"Dependency Injection (DI) in computer programming refers to the process of supplying an external dependency to a software component. It is a specific form of inversion of control where the concern being inverted is the process of obtaining the needed dependency."[3]

The two topics I want to hit on from Jordan's post are testability of code that's been subjected to IoC/DI and, more trivially, the naming of dependency injection.