Archive for July, 2011

The Gmail man

Here’s Microsoft latest ad against Gmail, the Gmail Man:

I find it hard not to groan while watching it.

Gruber likes it, though:

But it’s a fascinating competitive angle to take against Gmail.

It was a fascinating angle in 2005 while Gmail was still new and under all kinds of scrutiny, but today, who cares that your emails are automatically scanned, really? Even before Gmail, ISP’s already had the ability to read all your emails, but it has never really stopped anyone from using the email service of their choice.

I predict that this ad will get people to talk more about Gmail than the product it’s promoting (starting with myself).

This could also be considered deceptive advertising:

Google officials want it known, for the record, that there aren’t ads in Google Apps for Business. “But admins can choose to enable the ads if they want- some find them useful,” a Google spokesperson noted.

Erasure vs reification

Java 5 was released in 2004 and introduced generics to the language using a mechanism called “erasure”. In the following couple of years, a lot of discussions took place comparing this approach to its counterpart, usually referred to as “reified generics”. The discussions then tapered down for a few years, until recently when two languages brought this topic back on the scene by supporting reified generics. These two languages are Gosu (created and used in production by GuideWire) and Kotlin (under development, created by JetBrains).

There is a lot of literature available on the subject of erasure and reified generics, but I thought I would take a few minutes to summarize the current state of the world and share a few thoughts on the pros and cons of each approach.

Let’s start with a few concrete examples. Here are snippets of code which do not compile under an erasure system but which would work fine with reified generics. If you are not familiar with the issues involved, here is a short rule of thumb that should allow you to understand what is going on: whenever you see a generic type, replaced it with Object (since that’s exactly what’s happening behind the scenes):


public class Test<K, V> {
  public void f(K k) {
  public void f(V v) {
} name clash: f(K) and f(V) have the same erasure
  public void f(K k) {
              ^ name clash: f(V) and f(K) have the same erasure
  public void f(V v) {

The workaround here is simple: rename your methods.


public class Test {
  public <T> void f() {
    Object t;
    if (t instanceof List<T>) { ... }
} illegal generic type for instanceof
    if (t instanceof List<T>) {}

There is no easy workaround for this limitation, you will probably want to be more specific about the generic type (e.g. adding an upper bound) or ask yourself if you really need to know the generic type T or if the knowledge that t is an object of type List is sufficient.


public class Test {
  public <T> void f() {
    T t = new T();
} unexpected type
found   : type parameter T
required: class
    T t = new T();

This case is also a bit tricky but since it is, in my experience, more common than the others, I’ll spend a little more time discussing it.

As mentioned above, the virtual machine has no knowledge about the type T, which it only sees as an Object, so it won’t allow you to create an instance of it.

This is a good thing.

From a type standpoint, you know nothing about the T so you shouldn’t be able to instantiate it with the amount of knowledge you have. For all you know, T could be an abstract class, an interface or a class with no default constructor. In this case, type erasure keeps you honest by limiting what you can do on T to the operations that it knows about.

If you need to manipulate T, you will have to enable this through the type system. Do you need a new instance? Pass an additional Factory<T>. Do you need to call query()? on it? Create a type that contains this method and constrain T with it.

In 2006, Neal Gafter came up with a clever idea to make it possible to instantiate such erased types. He dubbed the technique “super type tokens”, and like most good ideas, it’s extremely simple: you force the creation of an anonymous class that contains the generic type, which you can then retrieve by a clever use of the introspection API.

Here is an example:

abstract class TypeReference<T> {}
public class TT {
  public static <T> void f(TypeReference<T> t) {
    ParameterizedType pt = (ParameterizedType)
  public static void main(String[] args) {
    TT.f(new TypeReference<String>() {});

This will print "class java.lang.String" on the console, even though the method printing it is completely generic. The trick is on the highighted line: notice the empty braces, which create an anonymous instance of TypeReference, setting the stage for the introspection code in the method to retrieve the generic type.

Shortly thereafter, Bob Lee picked up this feature, fleshed it out and included it in Guice under the name TypeLiteral. Scala supports a similar feature called Manifest.

Ever since Java 5 came out, and despite my initial fears, I can’t say that I have been bothered much by the absence of type information in Java generics, and I am tempted to generalize this observation to the general Java population. Erasure turns out to have quite a few advantages and as it turns out, reified generics come with their own set of issues. Here are some of them.

The main problem is that reified generics would be incompatible with the current collections. In binary form, for sure, and probably in source form as well (we would want to distinguish between collections making used of reified types from their older counterpart). Rewriting would probably be mostly a matter of copy/pasting, except for the parts that make use of introspection and which would need to be adjusted. The generated byte code would also contain more information. For example, the following test:

o instanceof List<String>

would now test that the object is an instance of List but also that its elements are of type String. That’s quite a bit more work.

The extra type information also impacts the interoperability between languages within the JVM but also outside of it. For example, Scala recently announced some progress on its .Net compiler, which contains the following caveat:

The key limitation for the moment is that Scala programs cannot use libraries in .Net that are compiled using CLR generics, such as the .Net collections.

This is just a consequence of the fact C# has reified generics, and bytecode containing this supplemental type information requires more work to be parsed and converted in a form suitable for the client, as opposed to a simple List type.

So, where does this leave us?

Erasure has proven to work quite well for Java, and actually for quite a few other languages as well. Besides the two languages that I named above, there are only two other popular languages that support reified generics: C# and C++. All the others use erasure of some sort, and overall, it’s hard to argue that either approach brings a significant improvement in ease of use.

All in all, I am pretty happy with erasure and I’m hoping that the future versions of Java will choose to prioritize different features that are more urgently needed, such as closures or an improved module system.

Oh, and happy Java 7 day everyone!

Exposing the trolls

Here is a wonderful piece from NPR’s “This America Life” about patent trolls. This one hour episode (make sure you get this one, not the shorter twenty minute version that aired on “All Things Considered”) sounds like a thriller, and it also describes in a chilling, outrageous and downright depressing way how patent trolls are eviscerating the hopes and dreams of real inventors and start up creators while imposing a mafia-like rule of silence to prevent anyone from discussing anything related to the matter.

The podcast is largely focused on Intellectual Ventures, a company created by former Microsoft CTO Nathan Myhrvold, who claims through the podcast through his Vice President Joe Chernesky that Intellectual Ventures’ only goal is to help inventors get the money they are due. The podcast tells a very different story.

I am hoping that this episode will be a turning point in the war against patent trolls and that something will finally be done about them, but the financial stakes in this market are so high that I’m not very optimistic.

Listen and see for yourself.

Let’s be serious about these Android return rates

This Techcrunch article is claiming a 40% return rate for Android phones:

However, on the ground, many return rates are approaching 40% said a person familiar with handset sales for multiple manufacturers.

This is an incredibly high number, especially considering that the return rate for the iPhone appears to be 1.7%.

Several things bother me about this article:

  • The author links to the source for the iPhone 1.7% number but provides absolutely no source for the main subject of the article. Where exactly does this data come from? A single person? Who happens to know the numbers for multiple manufacturers (emphasis on “multiple”, it’s important for the credibility of the article)? Who is that person? Where did they get this information from?
  • The article is implying that this return rate is for Android, not just a single handset. Seriously, can you imagine that every single Android handset has a return rate of 30%? Really?
  • No single company could come close to surviving such a high return rate, but hinting that every single manufacturer of an Android phone is seeing such a phenomenon? Absurd.
  • Guess where the numbers for the iPhone return rate come from? Well, Apple of course. To be fair, I don’t doubt that this number is probably accurate since I’ve seen nothing but very high satisfaction for the iPhone, but come on, Jason Biggs, show some professionalism: if you’re going to use Apple to support a side of your article, the least you can do is ask Google for their own numbers for Android phones.

Filed as “link bait”.

Five reasons why you should rejoice about Kotlin

As you probably saw by now, JetBrains just announced that they are working on a brand new statically typed JVM language called Kotlin. I am planning to write a post to evaluate how Kotlin compares to the other existing languages, but first, I’d like to take a slightly different angle and try to answer a question I have already seen asked several times: what’s the point?

We already have quite a few JVM languages, do we need any more?

Here are a few reasons that come to mind.

1) Coolness

New languages are exciting! They really are. I’m always looking forward to learning new languages. The more foreign they are, the more curious I am, but the languages I really look forward to discovering are the ones that are close to what I already know but not identical, just to find out what they did differently that I didn’t think of.

Allow me to make a small digression in order to clarify my point.

Some time ago, I started learning Japanese and it turned out to be the hardest and, more importantly, the most foreign natural language I ever studied. Everything is different from what I’m used to in Japanese. It’s not just that the grammar, the syntax and the alphabets are odd, it’s that they came up with things that I didn’t even think would make any sense. For example, in English (and many other languages), numbers are pretty straightforward and unique: one bag, two cars, three tickets, etc… Now, did it ever occur to you that a language could allow several words to mean “one”, and “two”, and “three”, etc…? And that these words are actually not arbitrary, their usage follows some very specific rules.

What could these rules be? Well, in Japanese, what governs the word that you pick is… the shape of the object that you are counting. That’s right, you will use a different way to count if the object is long, flat, a liquid or a building. Mind-boggling, isn’t it?

Here is another quick example: in Russian, each verb exists in two different forms, which I’ll call A and B to simplify. Russian doesn’t have a future tense, so when you want to speak at the present tense, you’ll conjugate verb A in the present, and when you want the future, you will use the B form… in the present tense. It’s not just that you need to learn two verbs per verb, you also need to know which one is which if you want to get your tenses right. Oh and these forms also have different meanings when you conjugate them in past tenses.

End of digression.

The reason why I am mentioning this is because this kind of construct bends your mind, and this goes for natural languages as much as programming languages. It’s tremendously exciting to read new syntaxes this way. For that reason alone, the arrival of new languages should be applauded and welcome.

Kotlin comes with a few interesting syntactic innovations of its own, which I’ll try to cover in a separate post, but for now, I’d like to come back to my original point, which was to give you reasons why you should be excited about Kotlin, so let’s keep going down the list.

2) IDE support

None of the existing JVM languages (Groovy, Scala, Fantom, Gosu, Ceylon) have really focused much on the tooling aspect. IDE plug-ins exist for each of them, all with varying quality, but they are all an afterthought, and they suffer from this oversight. The plug-ins are very slow to mature, they have to keep up with the internals of a compiler that’s always evolving and which, very often, doesn’t have much regards for the tools built on top of it. It’s a painful and frustrating process for tool creators and tool users alike.

With Kotlin, we have good reasons to think that the IDE support will be top notch. JetBrains is basically announcing that they are building the compiler and the IDEA support in lockstep, which is a great way to guarantee that the language will work tremendously well inside IDEA, but also that other tools should integrate nicely with it as well (I’m rooting for a speedy Eclipse plug-in, obviously).

3) Reified generics

This is a pretty big deal. Not so much for the functionality (I’ll get back to this in the next paragraph) but because this is probably the very first time that we see a JVM language with true support for reified generics. This innovation needs to be saluted.

Correction from the comments: Gosu has reified generics

Having said that, I don’t feel extremely excited by this feature because overall, I think that reified generics come at too high a price. I’ll try to dedicate a full blog post to this topic alone, because it deserves a more thorough treatment.

4) Commercial support

JetBrains has a very clear financial interest in seeing Kotlin succeed. It’s not just that they are a commercial entity that can put money behind the development of the language, it’s also that the success of the language would most likely mean that they will sell more IDEA licenses, and this can also turn into an additional revenue stream derived from whatever other tools they might come up with that would be part of the Kotlin ecosystem.

This kind of commercial support for a language was completely unheard of in the JVM world for fifteen years, and suddenly, we have two instances of it (Typesafe and now JetBrains). This is a good sign for the JVM community.

5) Still no Java successors

Finally, the simple truth is that we still haven’t found any credible Java successor.

Java still reigns supreme and is showing no sign of giving away any mindshare. Pulling numbers out of thin air, I would say that out of all the code currently running on the JVM today, maybe 94% of it is in Java, 3% is in Groovy and 1% is in Scala. This 94% figure needs to go down, but so far, no language has stepped up to whittle it down significantly.

What will it take? Obviously, nothing that the current candidates are offering (closures, modularity, functional features, more concise syntax, etc…) has been enough to move that needle. Something is still missing.

Could the missing piece be “stellar IDE support” or “reified generics”? We don’t know yet because no contender offers any of these features, but Kotlin will, so we will soon know. Either way, I am predicting that we will keep seeing new JVM languages pop up at a regular pace until one finally claims the prize. And this should be cause for rejoicing for everyone interested in the JVM ecosystem.

So let’s cheer for Kotlin and wish JetBrains the best of luck with their endeavor. I can’t wait to see what will come out of this.

Oh, and secretly, I am rooting for Eclipse to start working on their own JVM language too, obviously.

Link to the discussion on Google+

The Longest Journey

I took advantage of the recent Steam Summer Sale to buy The Longest Journey, which I had been meaning to play for a very long time.

It’s an adventure game released in 1999 which has won countless awards for its complex plot and high production values. Here is what Wikipedia has to say about it. Metacritic gives it a rare 91% score and the Amazon reviews are equally glowing.

I am about halfway through the game and I have to say that so far, the game is living up to its reputation. I would probably go as far as saying that this is the best adventure game that I’ve ever played (even better than Monkey Island and probably on an equal footing with Myst).

First of all, while the graphics look a bit dated (remember: 1999), they are quite adequate to convey the surroundings and the sense that you are moving through a universe that keeps alternating between familiar environments and different worlds. Take a look at the screen shot above, or this one:

It looks a bit pixellated on a big screen, but just like Minecraft, you quickly stop paying attention to this as you get more and more engrossed in the story.

The way I see it, an adventure game is typically judged on two major criteria, the puzzles and the story, and a bunch of minor ones, such as the UI, the save system, the graphics and the production.

The story

The Longest Journey has one of the richest and most interesting plots I’ve seen in thirty years of playing adventure games to the point where I wonder why it hasn’t been turned into a book or a movie. The premise is fairly standard but the details and the cleverness with which all the scenes are put together is what keeps drawing me back in.

I find myself going back to the game not to solve more puzzles but to find how the story will unfold and where it will take me, and that’s probably the biggest compliment you can pay to a video game.


The puzzles are overall very decent and logical. I’ve only had to look up a hint twice so far, which in hindsight I could have avoided if I had been more methodical in my exploration. When you have a problem to solve, you really need to ask yourself how you would solve such a problem if it were a real world situation. I found that keeping a list of the various items that you can interact with as you go from screen to screen helps. When you get stuck, you can revisit all these locations or, and it’s much faster this way, simply look at your piece of paper and go through all these objects one by one and try to imagine a way in which they could help you.

There is one big problem that all adventure games need to resolve in order to not frustrate their players, I call it the “missing data”. It’s very simple: when you are faced with a puzzle, do you have all the data at your disposal, in which case the puzzle is solvable, or are you missing one piece of crucial data, which means that no matter how many hours you spend thinking about this puzzle, you will never be able to figure it out?

In my opinion, the “missing data” problem is the reason why adventure games have fallen out of favor these days since it can be extremely frustrating to feel that you are wasting time working on an unsolvable problem.

There are two kinds of data that you can be missing: objects and locations.

Sometimes, solving a problem requires you to have visited a specific location which you never discovered so far. This can be either because this location is hidden behind another puzzle or because you simply missed it. The Longest Journey mitigates this problem by allowing you to see where all the exits are on each screen. If you press ‘x’, the game will show markers on the screen telling you which ways you can go from here. I found this pretty useful to make sure that I’m thorough in my explorations.

Missing an object is much more problematic, and for this issue, game designers have to walk a fine line between throwing problems that are too difficult to the players or by helping them too much. It’s not hard to imagine that a similar mechanism as the one above could be put in place in order to show you all the objects that you can interact with explicitly, but I think this might be going a bit too far (helping the player too much) and also contributing to a suspension of disbelief, which would take away from the immersion.

The Longest Journey doesn’t give you any hint on which objects can be interacted with, you just have to move your mouse carefully over each screen to discover these yourself. It’s not as tedious as it sounds and these objects are usually big enough that you can usually find them pretty easily (I only came across a couple exceptions so far). You need to do some “pixel hunting”, but I think the designers of the game found a good compromise here.

Other details

The voice acting is remarkable, especially from a game from 1999.

The UI is also very well done and striking a good compromise between being minimalistic while allowing a large set of options. When you click on an object, either you will get a description right away or a small menu with three items will appear: Look, Talk, Grab. Depending on the object and your progression in the story, not all of these options will always be available (for example, a character might not be willing to talk to you until you’ve solved a puzzle somewhere else).

You access your inventory with a right click but you can also materialize objects from your inventory with the keys ‘a’ and ‘s’, which allows for quick cycling. I much prefer this kind of interface to the one we find in the SCUMM games where you have to cycle through four or five different actions.

One last important touch: when you put in contact two objects that are expected to work together (which means, you are on your way to solving a puzzle), the object on your cursor will glow white. This is a very nice touch which, again, shows a good compromise between puzzles that are not too hard and not too easy.


I don’t have much to put in this section, honestly. As I mentioned above, I had to do some thorough pixel hunting a couple of times, but these are pretty rare and I consider this kind of task as coming with the genre. Another small problem I experienced a couple of times is moving the story forward. The plot is separated in several sections, and a few times, I knew I had just finished a puzzle and I was ready to move to the next chapter, but I wasn’t sure what to do. In such a case, make sure you revisit every single location you know and you will find that one of them has changed slightly in a way that will move the plot forward.


I am very pleasantly surprised to see that a twelve year old game can grab my attention like this. It’s another good example that playability will always trump graphics. Whether you enjoy adventure games or not, this is definitely a game you should consider buying if you like good stories.

Link to the Google+ discussion.

Accessing the class object in a static context

I often need to access the current class, for example for logging purposes:

public class Foo {
  private Logger logger = LoggerFactory.getLogger(getClass());

However, this won’t work in a static context, since you don’t have any this object to call getClass() on:

public class Foo {
  static private Logger logger = LoggerFactory.getLogger(Foo.class);

It’s always bothered me to have to copy/paste this line and then remember to replace the name of the class, so here is one way to make this snippet more generic:

public class ClassUtil extends SecurityManager {
  public static Class getCurrentClass() {
    return getClassContext()[1];

Which you use as follows:

public class Foo {
  private static Logger logger = LoggerFactory.getLogger(
      new ClassUtil().getCurrentClass());

A somewhat less hacky and cheaper approach is to instantiate an anonymous class in order to materialize a this object:

  private static Class thisClass =
      new Object() { }.getClass().getEnclosingClass();
  private static Logger logger = LoggerFactory.getLogger(thisClass);

Can you think of any other way?

Announcing TestNG 6.1

I’m happy to announce the immediate availability of TestNG 6.1.

You will find the full change log below but here are the highlights of this new version.

Improved syntax for factories

You no longer need to specify a separate factory method: you can now specify that the constructor of your test accepts a data provider and TestNG will instantiate one test class per set of values returned by the data provider:

public class FactoryDataProviderSampleTest {
  @Factory(dataProvider = "dp")
  public FactoryDataProviderSampleTest(int n) {
  static public Object[][] dp() {
    return new Object[][] {
      new Object[] { 41 },
      new Object[] { 42 },

Link to the discussion.

Support for ServiceLoader

If you’re not familiar with the tremendously useful class ServiceLoader, it’s a very simple facility to look up implementations of interfaces found on the classpath. This comes in particularly handy for TestNG when you want to define listeners and you don’t want to bother specifying them in testng.xml/ant/maven/annotations/whatever.

With ServiceLoader, all you need to do is create a jar file that contains your listener(s) and a few configuration files, put that jar file on the classpath when you run TestNG and TestNG will automatically find them.

Full details here.


The Eclipse TestNG plug-in has received a lot of improvements as well: more conversions from JUnit, new @Test refactorings, more control on the tree view (you can now clear it and you can specify stack trace filters), etc…

Thanks to everyone who contributed patches, ideas, feature requests and bug reports!


As usual, you can either use Maven:


or download the jar file directly.

Full Change log


  • Added: Support for ServiceLoader for ITestNGListener
  • Added: @Factory(dataProvider / dataProviderClass) on constructors
  • Added: assertNotEquals() to Assert
  • Added: assertArrayEquals() to AssertJUnit
  • Added: Nested classes are now automatically added for consideration for inclusion
  • Added: <suite preserve-order="true"> will cause this attribute to be propagated to all tags
  • Added: <groups> can now be specified under a <suite>
  • Added: Tycho compatibility (Aleksander Pohl)
  • Added: New <test> and <suite> flag: group-by-instances
  • Added: -xmlpathinjar to specify the path of testng.xml inside a test jar file
  • Added: ISuite#getAllMethods, to retrieve all the methods at the start of a suite.
  • Added: Output ITestResult attributes in XML report (nguillaumin)
  • Fixed: Thread safety problem in MethodInvocationHelper (Baron Roberts)
  • Fixed: Group dependencies were not being skipped properly.
  • Fixed: Dependency failures only impact the same instance
  • Fixed: Static classes could cause a StackOverFlowError
  • Fixed: IConfigurationListener was not extending ITestNGListener
  • Fixed: IConfigurationListener#onConfigurationFailure was never called
  • Fixed: TESTNG-476: <test> tags are now run in the order found in testng.xml
  • Fixed: Now showing failed/skipped error messages on the console for verbose >= 2
  • Fixed: ITestResult#getEndMillis() return 0
  • Fixed: TESTNG-410: Clearer error message
  • Fixed: TESTNG-475: @DataProvider doesn’t support varargs
  • Fixed: Performance problems in EmailableReporter
  • Fixed: TESTNG-472: Better output for assertNull()
  • Fixed: ConcurrentModificationException when using parallel data providers.
  • Fixed: TESTNG-282: Problem when including+excluding packages (addicted)
  • Fixed: TESTNG-471: assertEquals(Map, Map) fails if a map is a subset of the other
  • Fixed: JUnitReporter generates an <error> tag for successful expectedExceptions tests
  • Fixed: ISSUE-47: Don’t allow two <test>s with same name within same suite (Nalin Makar)
  • Fixed: If a listener implements both ISuiteListener and IInvokedMethodListener, only one of them gets invoked


  • Added: New quick fix “Add static import org.testng.AssertJUnit.assertXXX”
  • Added: New workspace wide setting: excluded stack traces, to provide shorter stack traces in the view
  • Added: New “Clear results” icon in the tool bar
  • Added: When the search filter is modified, don’t update the tree live if it is too big
  • Added: Two new @Test refactorings (pull to class level, push to method level)
  • Added: JUnit conversion: @Ignore
  • Added: JUnit conversion: assertArrayEquals()
  • Added: JUnit conversion: @RunWith(Parameterized.class)
  • Added: Support for Hamcrest failed assertions in the compare dialog
  • Added: JUnit conversion: suite() methods can now either be removed, commented out or left untouched
  • Fixed: JUnit conversion: super.setUp()/tearDown() were being removed when extending a class other than TestCase
  • Fixed: “Run as” menu not appearing for methods that take a generic parameter.
  • Fixed: The tree was incorrect if the same class is used in different <test> tags
  • Fixed: When creating a new Run/Debug configuration, “Launch.label” was displayed
  • Fixed: TESTNG-459: TestNG menu should not always be present in context menu (Mykola Nikishov)
  • Fixed: Performance problems in the plug-in
  • Fixed: Workspace-wide XML template files are not being honored.
  • Fixed: @BeforeClass/@AfterClass from JUnit4 are not being properly converted
  • Fixed: Conversions generate @Test() instead of @Test