why Properties extends Hashtable with Object parameter type instead of String?

[Zemian Deng]

Does anyone know why definition of java.util.Properties extends Hashtable<Object, Object> instead of Hashtable<String, String>? As stated by javadoc, Properties can and should only hold String right?

Also, is there better way to process a Properties entries without cast?

import java.util.Properties;
import java.util.Map.Entry;
public class Demo {
public static void main(String[] args) {
Properties props = System.getProperties();
for(Entry<Object, Object> entry : props.entrySet()){
String key = (String)entry.getKey();
String value = (String)entry.getValue();
System.out.println("processing " + key + " " + value);
}
}
}

Thanks,
Z

[Jeanne Boyarsky]

Zemian,
If the subclass used different parameter types, it wouldn't override the method. This goes back to the pre Java 5 days. When generics were introduced, they tried to keep backward compatibility with existing code that was using the Object API.

[Rob Spoor]

To be honest, I agree with Zemian. The only reason why old code would break if it were a Hashtable<String,String> would be if programmers put Objects directly into the Properties object using the put method. IMHO, that would mean using a Properties object in a way it wasn't meant to be used.

[Jim Yingst]

Yes, but the thing it, it is possible that people used put(Object, Object). Illogical as that may be, it's perfectly legal. It would have been better if Properties did not extend Hashtable in the first place - it should have contained one instead. But it's one of those bad design decisions that Sun made long ago, and now we're stuck with it. And Sun does take their backward compatibility very seriously, even here.

[Zemian Deng]

Right, backward compatibility. I was going to guess that. Well, I am glad some of you agree what I found. It just bugs me that with new Generic added, I still can't loop a Properties without casting.

Thanks for sharing your thoughts.
Cheers,
Z