There’s been a lot of activity in the TestNG world lately… Here are some highlights.

TestNG in Scala

Josh Cough has been busy working with TestNG and Scala. As a credit to Scala’s great integration with the JVM, it looks like the task was rather easy and Josh is showing a few examples in this blog post.

I notice two interesting pieces. First, a Data Provider:

@DataProvider{val name="generators"}
def createGenerators = {
val gens = Array(off, on)
for( x <- gens; y <- gens ) yield Array(x,y)
}

Notice how the same array is used to generate the two dimensions of the boolean matrix... This data provider will simply return the four possible combinations of "on" and "off" pairs.

The test making use of that Data Provider is fairly straightforward:

@Test{ val dataProvider="generators" }
def testAndGateStates(genA: Generator, genB: Generator){
val and: AndGate = new AndGate(genA, genB);
val whatItShouldBe = genA.on && genB.on
assertThat( and.on, is(whatItShouldBe) );
println( and.on + "==" + genA.on + "&&" + genB.on )
}

Notice also the appearance of HamCrest (assertThat).

ScalaTest

Bill Venners, from Artima, has also been busy cranking Scala code, and he came up with this nifty test framework called ScalaTest. His 0.9 release made the rounds and the discussion on Artima is now up to 58 replies(!).

Not surprisingly, Josh chimed in on the thread about the 0.9.1 release and TestNG support in ScalaTest was achieved in less time it took to write these words (I'm a slow typist). Talk about a match in heaven!

ReportNG

On a different front, the efforts to replace the default TestNG reports have not abated. First, there were Cosmin Marginean's XSL based reports, and now we have ReportNG, by Daniel Dyer, who uses Velocity to achieve grace and aesthetics in testing reports (who would have thought?).

Surefire 2.4 release

TestNG users who use Maven to build their code have been having a very hard time these past months. Because of various incompatibilities in the ways that TestNG and Surefire have evolved, TestNG users have been forced to use Surefire snapshots, which are notoriously unstable, and all kinds of mayhems and cryptic errors ensued.

These dark days are now over: Surefire 2.4 is out and it fully supports the latest TestNG releases.

Deleting SNAPSHOT files has never felt so good.

Book review

Finally, Masood Mortazavi likes our book so much that he decided to write a review. And we didn't even have to pay him!

And that's all for today...

An innocent blog post on Lambda the Ultimate has generated a storm of comments about the idea of a killer app for programming languages.

I’m sure you’ve heard this expression before, and the idea is very simple: it’s an application which, in and of itself, will promote its infrastructure (the operating system, or the programming language or the framework it’s built on) from obscurity to instant fame and de facto standard overnight.

For example, one might say that Microsoft Office was Windows’ killer app. Of course, this would be simplifying the equation somewhat since a lot of factors made Windows the success it is today, but you get the idea.

While reading through these comments, I started questioning the very existence of the killer app concept. Especially for programming languages.

Let’s start with Java. Does Java have a killer app? Did Java go through the transition “obscurity -> killer app -> fame”?

Back in the early Java days (circa 1996), there was one thing that made Java stand out from other languages. It doesn’t mean that Java was more popular than these languages, nor that it was gaining momentum: it’s just that it was attached to a particular concept that was unique to it and because of that, it received a lot of hype and was discussed heavily on Usenet and other forums.

Do you remember what that killer app was?

Applets.

Thanks to applets, Java was going to take over the world and redefine the web as we know it.

We all know what happened.

Applets never went anywhere, but Java had enough interesting properties that a lot of programmers started working with it in many areas, most of them never envisioned by any pundit at the time. Who would have guessed back then that Java would become the de facto standard on the back-end, sharing an equal footing with .Net in delivering millions of transactions every day to users around the world?

Let’s take another example: PHP.

Does PHP have a killer app?

None that I can think of. Of course, a lot of very successful programs and web sites are written in PHP (forums, blogs, etc…), but none of these can be considered “clinchers”. Instead, PHP became successful quietly, discreetly, behind closed doors, while both programmers and the required infrastructures (massive support by Internet Service Providers) were being slowly achieved without anyone realizing it. To onlookers, it looked as if one day we woke up, and PHP was everywhere. But make no mistake: the process was continuous, slow and developed on a massive scale.

A similar argument can be made for Javascript.

The more I thought about it, the more I started wondering if the idea of a killer app isn’t a fallacy. Or worse: a kiss of death. As soon as a programming language or a framework finds itself in need of a killer app, it has already failed and its proponents are just reaching and trying to save a product that they know is already slowly falling back into obscurity, as the rest of the world inexorably percolates toward the next big thing, one that makes them truly more productive and that doesn’t need bigot advocates to sell.

Maybe what we are really looking for is not a killer app but killer apps. Not one defining product by which all the others are measured, but a multitude of tiny ones which, individually, don’t really deserve any particular mention, but when put together, create a comfortable ecosystem in which programmers thrive, are productive and enjoy working in.

Now, let’s see if we can find the Next Big Programming Language using this criterion…

Time for Sun to rename its ticker symbol to “SQL”?

Rick Hightower posted an interesting follow-up to Zed’s rant against Ruby on Rails. There are a lot of insightful comments in this discussion, and one in particular caught my attention:

People are tired of dealing with Java’s many idiosyncrasies

I’ve been reading this a lot these past years but I’ve yet to see any evidence of it.

Come to think of it, this statement is mostly coming from bloggers, but…

• They don’t speak for all Java developers (actually, they represent a very tiny fraction of them).

• They need to drive traffic to their blog, and nothing achieves this goal better than posts titled “Java is dying” or “Ruby has won”.

I’ve been programming in Java for more than ten years. I have studied a lot of languages, and I keep learning new ones just out of curiosity. I even use some of these exotic languages here and there as the need warrants. Yes, some of these feel really good to program in (Ruby and Groovy for example), but at the end of the day, I still like Java. A lot.

Sure, there are things in the language that bother me, but it’s true for any language, and as a whole, I always enjoy going back to my favorite Java IDE and leverage its superb features to write code that I find is elegant and that achieves a goal.

Whenever I use a non-Java language, I always have this nagging feeling in the back of my head that something is going to hold this piece of code from ever becoming mainstream or used by a lot of people. It can be because the language is slow, or that it needs an interpreter. Or that it will be hard to deploy my program on a user’s machine. Or that this language was created before OO became mainstream and its support for new paradigms feels retrofitted and creaky.

Or that its support for floating point is very poor. Or that its thread API is primitive and the author of the language keeps saying that it’s no big deal and that you can do without that. Or maybe it doesn’t have any Web framework that supports internationalization, a clean MVC model or out-of-the-box testing. Or I want to write a client application that leverages its host operating system but all that it offers is an ugly-looking user interface and leaking metaphors.

None of these defects take away the pleasure I derive from sometimes straying off the beaten path and writing code in an exotic language, but it does set my mind into a mode that tells me that this piece of code will never be promoted past the “toy” status.

Toy listings are great for sniped blog entries, but a mainstream programming language they do not make.

Whatever your favorite language is, be it Scala, Ruby, Python or Groovy, I’m with you. I really am. I understand the warm glow you feel when you write code in your language because I feel it too. But what you need to understand is that there is very little chance that your language will displace Java in any way in at least the next five years to come.

But please, keep posting cute code snippets that show how great your language is, because I love to be challenged in the way I think and indirectly, Java benefits from all these great ideas that keep being posted in the blogosphere.