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

Relevant Pages

  • Re: Add to a string to make it continuous
    ... Build the entire string, then write to ... >>> Apples, Oranges, Peaches ...
    (microsoft.public.excel.programming)
  • Re: Assigning a type to a variable at runtime
    ... That will probably keep the taste of the apples and the pears ... > contains a string. ... for the above example I would want the equivalent of "dim ... > x.gettype would return 'MyClass' so I would want the equivalent of "dim y ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Just a bit of silliness
    ... supported by gcc, and issuing _in the definition of iprintf, ... returned by _("There are %d apples") won't be known until run time. ... How does that help you if the string checked by the compiler is not ... Bart v Ingen Schenau ...
    (comp.lang.c)
  • Re: The moment the willing suspension of disbelief died
    ... with two ends and pull it apart, and hand you half, you don't expect ... your half to be a string with one end. ... but which it turns out aren't quite) are common as mud; ... So if it turned out that apples were one of these, ...
    (rec.arts.sf.written)
  • Re: Sum.if date is in an interval...
    ... Now I just want to calcluate the number of occurances of a string in column ... D (e.g., the number of times "Apples, Oranges") are listed in the column. ... "Bernard Liengme" wrote: ... Microsoft Excel MVP ...
    (microsoft.public.excel.worksheet.functions)