The @Immutable transformation in earlier versions of Groovy tried to be smart
in the case of an immutable class with a single HashMap property, the supplied Map constructor
tried to be compatible with both expected tuple behavior and expected named-argument behavior
by peeking into the supplied map and guessing as to which approach might be applicable.
Recent versions of Groovy now allow both @TupleConstructor and @MapConstructor
annotations to co-exist which provide's a more flexible solution to this problem. While more
flexible, the new approach isn't fully compatible with the previous approach. If for some
reason you need the old behavior, you can try this property handler. Some features of the
new approach won't be available to you.