[COLLECTIONS] ExtendedProperties oddities

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[COLLECTIONS] ExtendedProperties oddities

sebb-2-2
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.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COLLECTIONS] ExtendedProperties oddities

Matt Benson-2

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: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COLLECTIONS] ExtendedProperties oddities

jodastephen
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 <[hidden email]> 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: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COLLECTIONS] ExtendedProperties oddities

Oliver Heger-3
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.

Oliver

>
> Stephen
>
>
> On 20 October 2010 16:32, Matt Benson<[hidden email]>  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: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [COLLECTIONS] ExtendedProperties oddities

Matt Benson-2

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<[hidden email]>  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: [hidden email]
>>>> For additional commands, e-mail: [hidden email]
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: [hidden email]
>>> For additional commands, e-mail: [hidden email]
>>>
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]