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.
---
