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<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
