Groovy isn’t a superset of Java

Coming from Java to Groovy and seeing that Groovy looks like Java with sugar, you are tempted to write code like this:

  private String take(List list) {
    return 'a list'
  }

  private String take(String s) {
    return 'a string'
  }

But when you call this method take with null you get strange results:

  public void testDispatch() {
    String s = null
    assertEquals('a string', take(s)) // fails!
  }

It fails because Groovy does not use the declared types. Since it is a dynamic typed language it uses the runtime type which is NullObject and calls the first found method!
So when using your old Java style to write code in Groovy beware that you are writing in a dynamic environment!
Lesson learned: learn the language, don’t assume it behaves in the same way like a language you know even when the syntax looks (almost) the same.

About these ads

12 Responses to Groovy isn’t a superset of Java

  1. [...] isn’t a superset of Java Groovy is Java with sugar, right?… [full post] jenslukowski Schneide Blog groovyjava 0 0 0 0 0 [...]

  2. Lautaro says:

    This is one of the reasons because I don’t like dynamic languages too mucho. However, I think that method overloading is not good neither (because of overlading, method parameters can’t be contravariant when inheritinh in Java), but with Groovy you could “accidentally” overload a method and get this kind of behavior.

  3. Rémi Forax says:

    In my opinion, it’s just a bug. You should post an email on groovy-dev mailing list to be sure.

    Rémi

    • jenslukowski says:

      Remi,

      I don’t think this is a bug. In some areas Groovy uses a different semantic than Java. And since Groovy is a dynamic language it uses the runtime type information. Null has a type of NullObject and so it loads the first method.

      • Rémi Forax says:

        The real question is why Groovy don’t use the static type info when the user provide it.

        I agree that Groovy is a dynamic language, so the dispatch is a multi dispatch (i.e not a Java dispatch) but the way Groovy handle null is wrong, it should use the type declared by the user.

        Rémi

      • jenslukowski says:

        Remi,

        I agree with you here, Groovy should use the static type info when provided. I once read that only insert a type check and do not use the type further.
        So actually inserting types in Groovy is bad in two ways: performance and expectation.

      • marky says:

        Anyhow, looks like a pretty good source of easy to commit and hard to find errors. Do you mean it’s enough to change the order of the methods and the test passes?

        If I’d designed groovy I’d probably treat this situation as an exceptional one, otherwise I’d try to warn the client about the arbitrary decision that is taken when choosing one of those two perfectly matching methods.

      • jenslukowski says:

        Marky,

        the test passes when you change the method order but I don’t think this helps. I think type declarations in Groovy can be dangerous in certain situations where you would expect another outcome because of the types.

  4. Method dispatch is one of the most important differences to understand between java and groovy. it is worth the time for new groovy users to spend some time learning it.

  5. While it’s true that it uses the runtime arguments, it doesn’t look like it picks the first method it comes to (at least with Groovy 1.7.10). It appears to look for the “most appropriate” method. At least, in my testing, it consistently picked the least specific method argument.

    So, no matter how I wrote it, it always picked the List method. However, when I added a version of take that has Object as the argument, it always used that method, even when I re-arranged the arguments.

    So, it’s still very true that you need to understand the method dispatch, and the difference between static and dynamic dispatch, but the results at least seem to be consistent and testable.

    It’s too bad about the null issue. It’s the only major problem area I see (and I’d argue that for all other instances, Groovy’s dynamic method dispatch is more “appropriate” – so that the most specific method is what is always called).

    Finally, as I found on Groovy Goodness, there’s a trick to ensuring that the method you want is called:


    // we may be looking at null values, so force the correct method call
    assertEquals('a string', take(s as String))

  6. [...] Groovy itself has been quite solid for a long time but things like dynamic dispatch with null values, boolean truth  and its  NullObjects (e.g. null + null == "nullnull"!) may yield some [...]

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

Join 64 other followers

%d bloggers like this: