[Pki-devel] Is clone method broken on /PropConfigStore?

I've come across a piece of code resistant to the Type safety cleanup, and I suspectthat it is broken, and we are lucky that it is never blown up. CMS.init calls DBSubsystem.init() which calls PropConfigStore.clone(). So this code path is executed. In the file: http://svn.fedorahosted.org/svn/pki/trunk/pki/base/common/src/com/netscap... the clone method calls Enumeration subs = getSubStoreNames(); while (subs.hasMoreElements()) { IConfigStore sub = (IConfigStore) subs.nextElement(); So the collection returned is expected to be filled with instances that implement IConfigStore. However, looking at getSubStoreNames: String pname = (String) e.nextElement(); int i = pname.indexOf('.'); // substores have "." if (i != -1) { String n = pname.substring(0, i); if (!v.contains(n)) { v.addElement(n); } } } return v.elements(); It is definitely filling the collection with Strings. My only guess is that the collection used does not have any of the paths joined with a dot, so the returned collection is empty. SVN shows this code was checked in this way during the initial import. I'm guessing noone here has touched it. I'm planning on changing it like this: - Enumeration subs = getSubStoreNames(); + Enumeration<String> subs = getSubStoreNames(); while (subs.hasMoreElements()) { - IConfigStore sub = (IConfigStore) - subs.nextElement(); + String subName = subs.nextElement(); + + IConfigStore sub = (IConfigStore)getSubStore(subName); If anyone objects, speak up now.