Properties not always [was: svn commit: r1209685 - /commons/proper/configuration/trunk/src/main/java/org/apache/commons/configuration/ConfigurationFactory.java]

[sebb <se...@gmail.com>]

On 3 December 2011 07:25, Stefan Bodewig <bo...@apache.org> wrote:
> Hi Oliver,
>
> On 2011-12-02, <oh...@apache.org> wrote:
>
>> Another attempt to fix the GUMP build using an ugly cast.

>> -        Map<Object, Object> systemProperties = System.getProperties();
>> +        // This is ugly, but it is safe because the Properties object returned
>> +        // by System.getProperties() (which is actually a Map<Object, Object>)
>> +        // contains only String keys.
>> +        @SuppressWarnings("unchecked")
>> +        Map<String, Object> systemProperties =
>> +                (Map<String, Object>) (Object) System.getProperties();
>>          MultiVariableExpander expander = new MultiVariableExpander();
>>          expander.addSource("$", systemProperties);
>
> The assumption you make here may not always hold true.  We've had
> several bug reports against Ant when we assumed the system properties
> would only hold string keys (or even values) and this simply was not
> true in cases where Ant code was used embedded in a larger application
> that was doing strange things.  java.util.Properties will not prevent
> you from putting objects into it.  I assume a commons component is at a
> bigger risk of such scenarios than an application like Ant.

That's very interesting; I suspect there are some other cases in
Commons where we have made this assumption.
[And probably in many other projects when converting to generics ...]

However, if one uses java.util.Properties.load() or void
java.util.Properties.loadXML() it should be OK, because the load
method only creates Strings?

> Even if it takes a bit longer it may be cleaner to create a new Map that
> contained a filtered view of only those properties that actually have
> string keys.

Good point.

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