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.
UPDATE:
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.
). 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