On Oct 20, 2010, at 2:25 PM, Oliver Heger wrote:
> Am 20.10.2010 17:37, schrieb Stephen Colebourne:
>> 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.
>
> The Javadocs of ExtendedProperties recommend using the
> PropertiesConfiguration class of Commons Configuration.
>
> Maybe the opportunity of a major Collections release could be used to
> deprecate or even remove this class? IMHO it does not really fit into the
> project.
>
+1, the fit is quite a stretch. -Matt
> Oliver
>
>>
>> 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
>>
>
>
> ---------------------------------------------------------------------
> 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
