Github user krichter722 commented on the issue: https://github.com/apache/storm/pull/459 > I checked a few of these, and it seems they have already been modified to avoid the compile errors. I seems like `IBolt.prepare`'s `topoConf` has been changed to `Map<String, Object>` everywhere which is a good idea (and a better idea than `<?,?>`). Now that the interface is improved in puncto type safety, the generic types should be used everywhere they're encountered/used anyway, but just not passed down or up the hierarchy. This applies to all topology configuration, metadata and authentication maps since they're using `<String, Object>` at some point in the hierarchy or in a relationship. I pushed those changes to the generics branch. Since this issue is about `IBolt` I can open a new PR, but it's very similar. I don't seem to be able to figure out the necessary type for `IScheduler.config` which is sometimes `Map<String, Object>` and `Map<String, Map<String, [Number or Double]>` which is possible in a non-type safe environment, but unnecessarily hard to understand. So, I let it untouched. There're a lot of usages of the idiom Map<String, Object> someMap; Map<String, Object> nestedMap = (Map<String, Object>) someMap.get("someLiteral"); which should imo be encapsulated in a configuration class since the map should contain nothing more complex than wrappers, maybe a single valued collection (list or set), but a map in a map value might cause problems at some point (and probably only does not now because of the excellent test coverage). Also, `"someLiteral"` is the [magic-number anti-pattern](https://en.wikipedia.org/wiki/Magic_number_(programming)#Unnamed_numerical_constants). > Yes, I'll retracting my -1. Sorry for letting this one languish. No problem. I'm aware that some of the changes do not introduce improvement immediately because Storm serializes and deserializes a lot, but the changes allow to discover design flaws and to fail earlier in case of a type mismatch.
---