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!

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”.

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.

On a related topic, somebody recently asked on the superuser.com 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?”

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) {
  p.name = "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.