ghost
commented
11 years ago Ken, great catch!
Leaving a quick note for myself, the issue Ken is reporting can be easily seen in initRules with any of the switch-case statements where the rule is attempted lookup by its name, then stored by its hashcode:
// Get the rule list for this path
ruleList = tagRuleMap.get(rule.getLocationPath());
// If there wasn't already a rule list, create and add it
if (ruleList == null) {
ruleList = new ArrayList<IRule<T>>(3);
tagRuleMap.put(rule.getLocationPath().hashCode(), ruleList);
}
Hello. In reviewing the XMLParser class code, I noticed that the initRules method looks up the rule key as a String but put's it into the same map as an int (hashCode). This may be a missed change when you improved the parse performance rule lookup from String to Hashcode. This issue shows up in all 3 rules maps.
The net result is a location path will always create a new rulelist and thus only ever have one rule associated with it (last rule definition wins for that path). This could lead to wasted memory and/or unexpected behavior.
KenJ