Re: java.util.Properties extending from HashMap<Object, Object> instead
of HashMap<String, String>
Zig wrote:
On Sun, 06 Apr 2008 01:45:15 -0400, Lew <lew@lewscanon.com> wrote:
If your speculation was correct, then java.util.Hashtable and
java.util.Dictionary would also be required to be of type
<Object,Object>.
No, because both those classes are parametrized. Properties is not.
Apples and oranges.
Changing the parameterization doesn't affect runtime compatibility:
methods with the initial erasure type for parameters and return types
*must* still exist at runtime. I've listed that in a bit more detail in
my initial response to Owen. If my logic is flawed there, please feel
free to correct it.
All right.
You proposed that to be "compatible" with pre-1.0 days, Hashtable and
Dictionary would have to be implemented as having <Object, Object> parameters.
However, those classes are defined to take type parameters ("K" and "V",
arbitrarily) - they are not treated only as the raw type. This is different
from Properties, which was *not* implemented as a parametrized type when
generics entered the language. That means it must settle on one, and exactly
one, assignment of types to the "K" and "V" parameters when it subtypes
Hashtable. Because it is a pre-generics class, Properties cannot reliably
specialize on <String, String>, even though that's the only intended use.
Formally, the only safe specialization is <Object, Object>, if one does not
wish to declare Properties as a parametrized type. Even though Properties was
*never* intended to hold non-String values, its formal structure admitted
them, so that had to carry forward into version 5 and onward. Hence <Object,
Object>. This reasoning cannot apply to classes that were fully generified
with parametrized types.
Type erasure and all that is a run-time consideration, and not relevant to my
point at all.
At most it would have affected compile-time compatiblity. Assuming users
Yes, that is the entire point. What is this "at most" stuff? That *is* the
point.
are using Properties as intended, this would be limited to users doing
things like:
Object o="foo";
new Properties().put(o, "bar");
This is an illegal use of Properties. Haven't you read anything I posted?
Sun calls such a Properties instance "compromised"; it will not function properly.
And Sun's usual answer for this is for users to use "-source 1.4" to
compile, until they have an opportunity to fix their source.
No, Sun's actual answer for this is to put only Strings in Properties.
--
Lew