Archive for January, 2011

Testing to the speed of light

When you are under pressure to ship a feature, every little detail that makes your coding process faster counts. Especially when it’s about writing tests. For example, if you are one of the many people who don’t use TDD, you first write a class, iterate a few times over the initial implementation and when you’ve reached a point where you are satisfied, you are ready to write a test for it.

With TestNG and Eclipse, writing tests just became easier.

The “New TestNG class” wizard has just received a new page that looks at the Java file that’s currently in your editor and then allows you to select public methods in it. Methods selected in this page will be automatically included in the generated test class, with a default implementation that throws an exception, so you don’t forget to implement it:

The wizard is also pretty clever in trying to stay as much out of the way as possible. For example, it will automatically detect the package, come up with a test class name and, more importantly, it will guess what is the most appropriate directory for your test class. For example, if you are using Maven, this directory will be src/test/java:

Happy testing!

Not too late, just inconsequential

Dan Lyons thinks the Verizon iPhone is arriving too late:

So who cares that now Apple will sell its phone on Verizon? For me, it’s too late. Other converts to Team Android tell me they’re feeling the same way. “I’m not going back either,” says Fred Wilson, who runs Union Square Ventures, a venture-capital firm in New York.

Dan cites diversity as the main reason why the new iPhone will have less impact than a lot of people say. He also dislikes the scarcity of choices available in the iPhone world:

The iPhone, in contrast, is a bit like the situation people once had with Henry Ford’s Model T, where you could have any color you wanted, as long as it was black. With the iPhone you can have whatever Steve Jobs says you can have.

Predictably, John Gruber disagrees:

The Model T was a massive hit, dominating the market for over a decade: Wikipedia says:

“By 1918, half of all the cars in the US were Model T’s.”

He also contends that the extreme control that Apple is exerting on the iPhone is the main reason for its success:

I’ll just point out that he posits as fact that “Apple’s control-freak nature” is a weakness. Control-freak does carry a negative connotation in our culture. Swap in the word perfectionist and it changes the connotation.

I agree with John on this point, nobody can dispute that the extreme control that Steve Jobs has on the design of the iPhone is the main reason for its success. Calling this “control freak nature” is a red herring: who cares how the process works as long as it delivers. And Apple has delivered brilliantly, no questions about it.

However, I think John’s point about the Ford Model T is flawed. Yes, the Model T had only one model available, and yes, it was a resounding success, but the correlation here is indirect. People were not buying the Model T because it had a great user experience but because it was the cheapest car available. The low price was indeed a direct consequence of the absence of choice (and of other factors, such as the early use of assembly lines) but the fact is that at the time, there were very few cars to choose from.

The situation is very different today in the phone market.

Price is of no consequence. Subsidized iPhones and Android phones are about the same price and the plans are comparable. Price is not the driving factor in the choice of smart phones these days. A few years ago, when the iPhone was reigning supreme, the deciding factor was that there was no phone that was even remotely as good as the iPhone, so the choice was easy.

However, in 2010, something radical happened. Something that immediately threatened the iPhone supremacy but that hardly nobody noticed.

Android became “good enough”.

By “good enough”, I mean that suddenly, you were always finding the iPhone and Android side by side in articles, TV shows, customer reports, blogs, newspapers. Android had managed to crawl its way up, to make itself credible, to catch up with the iPhone, something that most experts would agree was deemed impossible just two years ago.

And with this newly acquired status for Android, the debate suddenly shifted. The decision to buy a smartphone started relying on other factors. People started looking more closely at carriers, extra features (such as MMS, tethering). And the iPhone stopped being the shoo-in. Suddenly, it had to justify itself.

Going back to Verizon, I agree with John that Dan is probably extrapolating his personal situation a bit too far: just because he won’t switch doesn’t mean nobody will. But I disagree with most pundits who predict that the new Verizon iPhone is going to turn the tide and give the #1 spot back to the iPhone. That train has left the station. Just a few months ago, Android was already outpacing the iPhone in phone activations by more than 100,000 a day. No doubt that this number has increased today.

The Verizon iPhone will certainly create a spike in sales and activations in the next few months, but in the grand scheme of things, it will be just a blip on the graphs and it will have done very little to stop what looks like Android’s unstoppable rise to the #1 spot in market share, first in the US, then in the world.

You can file this down as “claim chowder”.

Parallel framework shoot out

The JVM concurrent (or parallel, I’m using these terms interchangeably although I’m aware they have subtly different meanings) worlds has been exploding with activity and innovations lately. It all started with the now veteran but extremely well designed java.util.concurrent package and more recently, we have seen Scala enter the fray with its Actor Model, Groovy with GPars and Doug Lea’s Fork Join Framework (PDF). Let me know if I forgot any.

I find all these frameworks intellectually interesting but I’m still not quite convinced that either of the incumbents is superior to java.util.concurrent (although if I had to pick one, it would probably be GPars). Interestingly, all these frameworks intend to simplify concurrent programming but a lot of these claims are going pretty much unchallenged, or supported by trivial exercises that are biased toward the framework’s own documentation.

I’m keeping my mind open but so far, I haven’t seen any blinding proof of either of these superiority claims. What I would really like to see is a non-trivial (i.e. requiring a few hundreds of lines of code to solve) concurrent problem written with java.util.concurrent and other parallel frameworks and a tentatively objective analysis of the pros and cons of each approach, on several axes: maintainability, testability, readability (more subjective), debuggability, performance, reliability, etc…

My gut feeling is telling me that while the Actor/Immutable/lock free model appears simpler, it also introduces a radical shift in the way you implement your solution that might be detrimental to its maintenance on the long run. At the end, you might end up with a simple locking model (since there are no locks) but at the expense of a more spaghetti-ish structure, since all these actors are now sending asynchronous messages to each other and retracing and debugging such a flow can be challenging.

Another gut feeling that I haven’t been able to shake off is the fact that the actor model introduces a single locking choke point (the inbox queue) while Java’s traditional locking approach allows you to position your lock wherever you want, and over an arbitrarily large (or small) portion of code. Determining such a locking can be challenging, but once you’ve solved that particular problem, it’s hard for me to imagine that there are more optimal ways of solving this problem.

I’m pretty optimistic about GPars because it’s built on top of java.util.concurrent while offering Groovy’s more compact syntax, which has the benefit of being simpler while very accessible for Java programmers.

The first step would be to come up with a non trivial problem that is a good match for a parallel implementation… Any suggestions?

Update: here is a timely discussion about someone expressing the difficulty they’re having switching to an asynchronous mindset.


This cute clip shows young kids exposed to “old” technology and asked to guess what it was for. The video is in French but with English subtitles. The reactions are very cute and interesting, and I’m not sure what to think about the fact that I used all these items except one (the eight track player).

On a related topic, somebody recently asked on the site what the drives A: and B: are used for on Windows

This technology is barely twenty-thirty years old and it’s not just obsolete, it’s already almost forgotten. Soon, all these items will need a special mention in history text books…

“When you took a picture, you had to wait for several days before you could see it? Surely you’re joking, Daddy?”

Value or reference?

Death and Taxes are not the only two things that are certain in life: the regular resurgence of the “Is Java pass by value or pass by reference?” controversy comes to haunt us regularly as well. This year, it’s brought to us in the LinkedIn Java group and on TheServerSide.

Like all debates centered around words, it’s pretty hard to get a final resolution when most participants don’t agree on the meaning of these words.

This question makes for a great warm up interview question, though, but it would be pretty evil to ask it in these ambiguous terms, so instead, I simply prefer to show the candidate the two following snippets:

public void foo1(Person p) {
  p = new Person("Joe");
public void foo2(Person p) { = "Joe";

and then ask them to explain what these two methods do.

The number of candidates who hesitate (and sometimes get it wrong) is pretty surprising. As is the amount of discussion that sometimes follows this question.

At any rate, the ensuing conversation is always interesting and it usually makes the candidate more comfortable for the rest of the interview.

One click test conversions

If converting your tests to TestNG is one of your new year’s resolution, you are in luck.

Introducing the improved JUnit to TestNG converter.

A couple of months ago, I gave a preview of the new features in the TestNG Eclipse plug-in and I observed that more and more people were converting their tests from JUnit 3 and JUnit 4 to TestNG. This latter was a surprise to me since I never really expected anyone would want to move away from JUnit 4 once they have migrated to it.

TestNG has long supported individual class conversions in the form of Quick Fixes:

I recently expanded this support and turned it into a full refactoring, which means that you can now apply it to entire packages, source folders or even projects.

To use it, install the latest TestNG Eclipse plug-in, open your Package Explorer and right click on either a package, a source folder or a project:

The refactoring wizard contains two pages.

The first one lets you customize the testng.xml that’s about to be generated (you can also choose not to generate one):

The next page shows you a view with all the changes that are about to be made to your source files. These changes are similar to the ones made with the Quick Fix except that they now apply to multiple files:

On this page, you can exclude certain files from being converted, and when you’re happy, press the Finish button.

Like all refactorings in Eclipse, you can undo your changes in one click if you change your mind:

In a next post, I’ll show how you can use this new functionality to help you check that your unit tests are as isolated as you think they are.

Now go ahead and convert your tests, that’s one less new year’s resolution you have to worry about!