Essentially, a more valid version is in [configuration] IIRC, but this
one remained because people didn't want to load another jar just for
this "simple functaionlity". All IIRC.
Stephen
On 20 October 2010 16:32, Matt Benson <gudnabr...@gmail.com> wrote:
>
> On Oct 19, 2010, at 9:29 PM, sebb wrote:
>
>> IMO, the ExtendedProperties class has rather odd behaviour.
>>
>> It is documented as an extension of normal Java properties, yet it
>> allows Objects to be used as values:
>>
>> addProperty(String, Object)
>> setProperty(String, Object)
>>
>> The save() method ignores anything but String and List<String>, so it
>> won't save such values.
>>
>> The following sequence fails:
>>
>> eprop.addProperty("xxx", "true");
>> eprop.getString("xxx");
>> eprop.getBoolean("xxx");
>> eprop.getString("xxx"); // ClassCastException: 'xxx' doesn't map to a
>> String object
>>
>> This is because the call to getBoolean() replaces the String value
>> with a Boolean value.
>> Presumably this is intended to make it faster to retrieve next time,
>> but it's rather unexpected for a get() method to change the value.
>>
>> Is this behaviour really intended?
>>
>> If there really is a use case for including non-String values, then it
>> seems to me that load() and save() ought to handle these.
>>
>> In any case, it seems to me that the get() behaviour ought to be changed.
>
> No comment, other than that now you can see why I didn't touch this class
> when I was working in the branch.
>
> -Matt
>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
>> For additional commands, e-mail: dev-h...@commons.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
