commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [COLLECTIONS] ExtendedProperties oddities
Date Wed, 20 Oct 2010 19:30:36 GMT

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<gudnabrsam@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-unsubscribe@commons.apache.org
>>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message