commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Duncan Jones <>
Subject Re: [lang] LANG-975
Date Tue, 14 Oct 2014 13:07:05 GMT
On 9 October 2014 19:17, Benedikt Ritter <> wrote:
> I'm not fond that we need this method. However you're raising a good point.
> BooleanUtils only "talks" english. It understands "yes" and "no" but not
> "ja" and "nein" or "oui" and "non". It would be nice to have a possibilty
> to make the toBoolean(String) method work for other langues.

We have toBoolean(str, trueString, falseString), which helps to some extent.

To make this class more universal, we could add an overload that
accepts Sets of strings for both false and true, meaning that
toBoolean(String) can be emulated for other languages and arbitrary
groups of true/false values. I'll raise an issue to suggest this.

Meanwhile, I've closed the currently discussed issue (975) since we
don't really have anyone in favour of it.

> OTOH this can easily be implemented in a custom MyAppBooleanUtils which
> delegates to commons BooleanUtils and passes the correct default values.
> 2014-10-09 16:25 GMT+02:00 Filippo Balicchia <>:
>> Hi James,
>> IMHO I can't see the real need for this improvement,
>> any way, I disagree with this case
>> BooleanUtils.toBoolean(null, null) = true
>> Regards
>> --Filippo
>> 2014-10-09 9:49 GMT+02:00 James Sawle <>:
>> > I have created a patch for the above issue, which adds a new method
>> signature to simplify the conversion from Strings to Booleans based upon a
>> single true boolean String. This is therefore unlike the other methods,
>> which either take no parameters (use a prebuilt list of true and false
>> values), or require the user to provide a true, false and null value that
>> the parameter must match.
>> > It has been pointed out by Duncan Jones, that this is jus syntactic
>> sugar, due to it purely wrapping the StringUtils.equals method. Therefore
>> the question is, whether having this simple method would drastically
>> improve readability in calling code, or whether this would just be code
>> bloat for the sake of it.
>> > Personally, there is another option, which would be to have a version of
>> the method that takes a varargs of true values. This could therefore be
>> more useful in general cases, and could be used to simplify some of the
>> underlying String to boolean conversions. However, it should then be noted
>> that this would just become a contains check, with added protection around
>> null values. This would possibly also be more used to StringUtils with a
>> wrapper method within the BooleanUtils, which again raises the question of
>> code bloat.
>> > Any comments would be much appreciated.
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> --

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message