Re: java.util.Properties extending from HashMap<Object, Object> instead of HashMap<String, String>

Zig wrote:
but note one difference:

"Properties whose key or value is not of type String are omitted"

Yes, but more importantly,
Because Properties inherits from Hashtable, the put and putAll methods can be applied to a Properties object. Their use is strongly discouraged as they allow the caller to insert entries whose keys or values are not Strings. The setProperty method should be used instead. If the store or save method is called on a "compromised" Properties object that contains a non-String key or value, the call will fail. Similarly, the call to the propertyNames or list method will fail if it is called on a "compromised" Properties object that contains a non-String key.

Zig wrote:
I think this is an indication that, while Properties are *meant* for Strings, there may be existing code which uses them for other things.

Not if their authors read the Javadocs there isn't.

Current developers using those APIs may need some awareness that, if the Properties has passed through a 3rd party API, the developer is not guaranteed that casting each key or value to a String will be successfull.

It had better be, and no casting should be needed.
<http://java.sun.com/javase/6/docs/api/java/util/Properties.html#getProperty(java.lang.String)>

takes and returns String anyway, so why cast? Likewise with
<http://java.sun.com/javase/6/docs/api/java/util/Properties.html#setProperty(java.lang.String,%20java.lang.String)>


I just don't get all this silly talk about using non-String items in a Properties.

* The type has to be <Object,Object> due to backwards compatibility issues for APIs which used Properties in ways it was not intended for.

That's not it. It's because that's the only backward-compatible type for a class that came from 1.0 days. It's for APIs that used Properties in ways that it *was* intended for.

I think it would be useful if Properties were more Map-like. One might

But then it would be less Properties-like.

Oh well, I guess that's just nit-picking. Maybe Apache Commons Collections will offer some good replacements in the future.

Unlikely, since Properties does the job just fine already.

--
Lew
.

Relevant Pages

  • Re: HashMap toString, what about the other way?
    ... use a Properties object with its more specialized save and load methods. ... saving one string per line ... saving as a CSV file. ...
    (comp.lang.java.programmer)
  • Re: Danger of using FillMem() on a string? Speed of Abs()?
    ... doctors the string and then uses Dialogs.ShowMessage; ... >Hmmm, how do they do it on other OS's? ... 'Front' the APIs with your own version ... The nervousness is not about trying things out ...
    (comp.lang.pascal.delphi.misc)
  • Re: accessing protected storage and/or crypto API
    ... From my searches in MSDN I have found the PStore COM APIs which seem to do ... best to use a one-way hash algorithm on the password string, ... The key here is that the password cannot be ascertained from this blob, ... For an example of using the CryptoAPI in VB to perform a hash, ...
    (microsoft.public.vb.winapi)
  • Re: Windows machine name
    ... Most APIs have constants defined or referenced that specify the particular ... Dim tmp As String ... "Bob Butler" wrote in message ... :> When setting buffer sizes, how do you know how large to make them? ...
    (microsoft.public.vb.general.discussion)
  • Re: Defined a Fixed Length String in a Structure
    ... >> Some Win APIs expect a structure with a fixed length string. ... >> Dim dwOSVersionInfoSize As Long ... > it to the VB.NET marshaller that converts it back into unicode... ...
    (microsoft.public.dotnet.languages.vb)