During my recent week at the JavaOne conference, I attended several sessions dealing with issues of concurrency in programming. What started as a cursory interest, turned into a strong desire to really understand these problems at a deeper level. But I’m still really a noob when it comes to this stuff, so I figure this is a great time to try to explain it to other beginners.

Ok, let’s start with the basics, what is concurrency and why should you care? Well according to Wikipedia concurrency is

a property of systems in which several computations are executing simultaneously, and potentially interacting with each other. The computations may be executing on multiple cores in the same chip, preemptively time-shared threads on the same processor, or executed on physically separated processors.

Unless you’re writing applications that only have a few simultaneous users, chances are you will use the threading features of java to try and take advantage of the performance benefits of asynchronous processing. Even if you are writing a simple MVC style web app, that servlet container is going to be multi-threaded and you could encounter concurrency issues in your servlet code. The problem is, when we’re coding our app, it’s only ever exercised in a single-user scenario. And you can’t really write unit tests to check the behavior of multi-threaded areas of your code. Therefore, concurrency issues tend to not be identified during testing. Usually they appear as strange, random bugs during periods of heavy load, and cannot be reliably reproduced. Awesome. I love those.

So how do we identify the areas of our application that are susceptible to concurrency issues, and how do we code for them? Those are some pretty tough questions, I’ve found. Maybe by the end of this series we’ll have some answers. In the simplest of terms, managing concurrency means managing the shared state in your application, more specifically, mutable shared state. That really means any instance or static class level fields that are not declared as final. (There are some nuances to the use of the final keyword, but let’s keep it easy for now).
To control concurrency issues, follow 3 rules:

Don’t share state across threads. This is done by encapsulating your state. In the simplest example, this means that class fields are private and access is limited to one or two methods. This will make it easier to create code that is thread-safe.

Make your state immutable. If the value of your fields cannot be changed, you are already thread-safe! Consider exposing read-only versions of your objects when possible.

Finally, synchronize access. Only allow a single thread to access your state at any given time. Most concurrency discussion centers around locking and synchronization.

What does it mean to synchronize access? Synchronization is about controlling access to state and is handled primarily through locks. Proper synchronization guarantees 2 things:

Mutual Exclusion – this guarantees that only one thread can hold a given lock, and therefore only one thread has access to the locked state(data).

Visibility – this guarantees that as a thread releases a lock, any changes made to shared variables, the mutable shared state, will be immediately seen by all threads, most importantly the next thread acquiring the lock. This ensures that no threads see stale data.

So, concurrent programming in a nutshell:

Limit the mutable state (data that can be changed) in your objects. When allowing others to access and change your objects state, control that state using proper synchronization.

So that’s the absolute basics on concurrency, but what about Java?
The fundamental power of java is its memory model and the threading facilities that are built into the language. Along with thread support are many mechanisms to correctly handle concurrent operations. And this will be the subject of the rest of this blog series. Stay tuned.

This is a puzzler we created at my work to use as an interview problem. I had a fun time taking it myself, and got it wrong the first time! It was designed to mimic some bad legacy code you might encounter when working on a large aging system, that has passed through many hands. Terrible coding practices, no javadocs or comments, etc. You are tasked to figure out what the heck it does.
First – does it compile? If not, how do you fix it?
Second – If it compiles, what is the output?

I just returned home from a week in San Francisco at the JavaOne conference, I mean literally like 2 hours ago. This is the first time I’ve been to any conference like this, and I had a great time! The scale of this thing is really impressive, I mean it’s huge. The planning and logistics that go into putting on a conference of this size just amazes me. It felt like they really went all out, all the small details were handled, and you could see the effort they put into making it a special experience.

I had originally registered for tech sessions Tuesday – Thursday, but Thursday night I just wasn’t ready for it to end, and ended up cramming 2 more sessions in on Friday morning before jumping in a cab for the airport. I literally was in a cab 15 minutes after my final session.
Overall, I attended 19 technical sessions over 3 1/2 days, plus the general session keynotes.

I attended sessions on the different dynamic scripting languages that run on the JVM, many on concurrency, and then some on how to use those dynamic languages to solve concurrency problems. I had sessions on Spring, and REST using JAX-RS, sessions on unit testing and some of the tools available. I had a session on defective java with the man behind FindBugs, and a session on Effective Java (2nd Edition)
with one of the absolute rock-stars of the java world, Joshua Bloch. My session on Spring 3.0 was given by THE man behind Spring, Rod Johnson. My sessions on Lift and Clojure were both given by the creators of the language, and the session on JAX-RS was given by the writers of the specification. When I went to hear about how the Google App Engine now supports java, it was directly from the 3 guys responsible for it. I mean, talk about getting it from the source! That google session led to a very late night with my co-worker as we sat in the bar playing with the new sdk until 1am! Read the rest of this entry »

Update: Some comments were mysteriously deleted, sorry if yours is not appearing, thanks for commenting though! One person responded that they needed to install the XCode tools first. I think they were building or upgrading ruby (which I didn’t do). There are certainly no issues with doing this step first, I just didn’t need to until I installed mysql.

I just recently finished tackling this oft attempted-failed-blogged-fixed(but not for you) ritual, getting a working ROR sandbox with mysql.
Many others have blogged about this, trust me I spent many days reading them, and the approaches and results are all over the map.
Sorry to say, this post is not the be-all end-all solution that other blogs claim. It’s just what I did, posted mainly for my own documentation.

First, my requirements. My web host, Site5, currently has installed Ruby 1.8.7 and Rails 2.2, plus MySQL 5.1.x. So I wanted my dev environment to be close to what my deployment environment will be.
I prefer to understand as much about my dev environment as I can, I want to know how things work, so that I can control them. So magic out-of-the-box solutions generally aren’t favored.
However, I’m generally the person that does it the hard way, and also runs into all those problems that people post about on the web, it never just works. And I’ve got a lot of grokking ahead of me as it is, so taking the easiest approach migh not be bad this time.

After researching this, I boiled down the options to 3 popular approaches:

Use the default mac installation of ruby, upgrade the rails gem and install mysql

Build an entirely new environment from scratch, as detailed in the oft-cited Hivelogic article.

Option 1 seemed to be the easiest, but Leopard comes with Ruby 1.8.6 installed, I will use 1.8.7 in production, probably not a deal breaker. Also there is a potential that a future OS update could break something in my existing sandbox.

Option 2 gives me the magic all-in-one solution, but I always worry that I’m putting myself in their box. Plus the community seems pretty split on macports in general.

Option 3 gives me total control, and the best chance for everything going to hell.

In the end I decided on option 1, use the existing mac install and upgrade rails. I figured I start there, the other 2 options are still open to me if I find its needed.

“Finally, just get to it”. Surprisingly, everything worked very well, here’s how I did it.

In order to upgrade to 2.x rails gem, the gems package manager must be updated.

Ok, time install mysql. First thing is to make sure Xcode tools are installed.

If you have your Leopard installation DVD, load it now. If you don’t have an installation DVD, you can download the Xcode 3.0 tools at Apple’s Developer Web Site. (Note: Apple developer accounts are free.)

Open the Optional Installs folder, and then the Xcode Tools folder. Double click on the XcodeTools.mpkg installer and select a standard install. This will take a few minutes to run.

Download MySQL from their site. Make sure to get the 32-bit mac version.
This a native mac application and is installed like any mac app.

Once mysql has been installed, the mysql gem must be installed.

There seem to be 2 secrets to make it work. First you point the gem to the mysql client config folder, instead of the mysql home. Second, if on an intel machine, provide the env ARCHTYPE flag.

But I did just buy my first one. After a lifetime spent mastering windows, I never had a desire for a mac, and the fact that all the cool kids were getting them, made one even less desirable.
But lately I’ve wanted to get into some iphone development, and a mac is required. Also, I’ve really needed to purchase a new laptop. I’ve been using my work laptop as a personal computer for years, but it always feels borrowed.
So, given that the new intel based macs do a great job of running windows as well, I swallowed my pride and bought a macbook pro.

Now, I’m not going to get all fanboy about this. They do have a great aesthetic and its a pretty tight user experience, but in reality, as much as Vista has been bashed, the UI experiences aren’t that far apart. This isn’t some mystical new experience in computing. But I’ll save final judgment until I’ve really used it for awhile.

The first thing I really like about it, is that the terminal is a bash shell, no crappy ms-dos prompt. Plus 100 for the mac. The other thing I really love is that it seems to run MUCH cooler than my Dell, which would be burning up my lap in about an hour (yes I use a laptop on my lap).
But for all the talk about how great the design and UI is, I find that I don’t like the fact that every application looks like iTunes. It just gives it this rigid cold feeling, where every single app has to comply with the “apple way”. No individuals in this world.
I’m having a hard time adjusting to the command key vs ctrl on windows. Also, Apple provides a Control key as well, but I don’t know what it does. So far I use it just to control-click the track pad to enable “right-click” type features. Also, the mac keyboard has the “fn” key where the ctrl key is on windows, so I’m constantly hitting that by mistake. And I don’t like the key spacing on cut/paste which is cmd-c/cmd-v. I’m just so used to doing with my pinky and index finger on windows, the cmd and c/v keys are too close together. So I just have to get used to that I guess.
But my biggest beef is the menu bar. I’m not used to looking to the top of the screen to see the application controls, I expect them to be at the top of the application’s window. So I find myself constantly clicking around and application, trying to find a menu I’m looking for, until I final remember, “oh yeah, it’s up there”.
I’m not bashing it though, just the initial perspective of new user, coming from an alternate system.
We’ll see how it goes.