Grails 2.5.4 upgrade developer details

As promised we are starting a thread to help support you during the Grails 2.5.4 upgrade. I have been in close contact with our engineering teams over the last week and we are confident this upgrade will be transparent to most. For more information on why we are upgrading please read Alex’s note posted earlier this week.

This thread will serve as living notification for anything we notice as we move along with the Grails upgrade. For now I will speak to two changes we noticed that could affect some development.

The new version of Groovy that comes with Grails returns a different type of map when using jsonSlurper. In the past it returned a java.util.HashMap but will now return a groovy.json.internal.LazyMap. This will only affect those who were checking the exact type of the map when parsing json. We did some digging and most instances of this are in the Hue implementation. If you are using our published version of the Hue implementation it has been updated already, but if you are using a version of your own from our GitHub we encourage you to make these changes. If you have something like the following in your app:

if (body instanceof java.util.HashMap)

The quick simple fix is to change it to check for a map like this:

if (body instanceof java.util.Map)

These changes are beneficial because it will allow your SmartApp and Device Handlers to be more robust since they will be decoupled from a specific implementation due to HashMap and LazyMap inheriting from the same interface so your app will be more future proof.

Next, there are some edge case changes to methods that may impact development as well. In our current version of Groovy there are some bugs that people may have relied on that will cause errors when we upgrade. The first example of this is in an overloaded method. In the current Groovy implementation something like this would have worked:

class Test {
    def foo(List f) {}
    def foo(Map f) {}
    def foo(String f) {}

new Test().foo(null)

The new groovy version is a little more strict than the older one and requires the type to more closely match the arg. In this case the simple fix would be to add a def foo(Obj f) method since “null” is closer to an object than a list, map, or string.

Second, there was another bug that allowed the overloaded method to have a different return type. Something like this:

Object method(List l) { … }
String method(String s) { … }
void method(Map m) { … }

This will now cause compilation errors. So in essence for overloaded methods, things are just more strict.

For now that is all we have seen that could cause some development hurdles, but we don’t expect many people to run into these edge cases. If you have any questions please let us know in the thread below and we will make sure to answer any questions you have.

I will update this thread when it has been completely deployed.


We pushed to a few production canary servers and noticed a few problems. We have rolled it back for now and are evaluating what went wrong. I will keep you all updated as to the new timeline for the release.


Tim has this been deployed? I found another change yesterday which impacted an app that working.

While checking of the current mode is in the list of user selected modes, this is what was working as of last week:

if (notify && (notifyModes ? notifyModes.find{it == (location.currentMode)} : true))

now one needs to do:

if (notify && (notifyModes ? notifyModes.find{it == (location.currentMode as String)} : true))

I know it’s supposed to be location.mode or to be technically correct, but just wondering if that’s anything to do with the more strict rules.

It has not been deployed.

Scheduled for tomorrow.

1 Like

That settles it :slight_smile:

1 Like

I hope foo isn’t short for fubar!! Not looking forward to coming in and seeing all my legacy devices and apps dead because the rules are stricter than before.

If you’re not using a custom hue integration it shouldn’t cause any problem for you.

Also, if you haven’t received an email from me you’re not affected. :slight_smile:


Time to go check ny email. Double check. I think I used HashMap a couple of times, will replace that with Map.

Update on the rollout:

We pushed to a few production canary servers and noticed a few problems. We have rolled it back for now and are evaluating what went wrong. I will keep you all updated as to the new timeline for the release.



So, it’s been a little while since we heard anything about Grails… how’s that coming along?

1 Like

We spent some time trying to tune the Garbage Collector in production but progress was slow - we ended up rolling the change back because we wanted to release the change by itself to minimize risk and as more development work was being checked in managing the different branches became difficult and prone to error. We also had enough heap dumps, logs, etc… to analyze at that point. Shortly after that, the loss of state event occurred and we shifted focus on triage & mitigation but you know how that ended up. (I know saying sorry won’t bring your state back but sorry :frowning: ). Then shortly after that we started seeing some serious issues around timeouts in the scheduler cluster for NA01. Our team (Platform Performance & Reliability) then switched focus on that. I think we’re at a place now where we are comfortable with the schedulers performance without having to rely on rolling restarts because of the awesome work that @rappleg did. That’s basically the timeline up until early this week - we will likely start looking at digging back into tuning for the upgrade but keeping the platform stable will always take priority over getting this upgrade out.


Welp, another great update from Vlad.

No doublespeak. Up front. Straight to the point. Clearly not language ran through a bureaucracy and sanitized.

I know you’re busy when the stuff hits the fan, but this is the type of transparency that builds trust.

Vlad for President.


Was this ever rolled out?

The following Method doesn’t work:,%20java.lang.String,%20java.util.TimeZone)