Hi Basil,
On 11.08.2025 21:44, Basil Crow wrote:
> I am bringing this to the list for broader discussion. What are your
> thoughts on the trade-offs? Does this seem like a worthwhile
> simplification, or are there concerns I am missing?
>
> If we can reach consensus here, I would like to proceed with the change
> (potentially with adjustments based on feedback).
I don’t see a major simplification in either approach, nor a significant
performance difference:
- `String.equalsIgnoreCase()` is probably slightly slower: it doesn’t
benefit from cached hashes and compares each character twice (once
lowercased, once uppercased). A series of `if` statements is also
slower than a `switch` and, in my opinion, less readable.
- The current approach incurs the extra cost of a `String.toLowerCase()`
call.
Scope of discussion
-------------------
I think there are two questions here, depending on how internationalized
we want `BooleanConverter` and `ColorConverter` to be.
1. English-only
If we only need to handle English names for booleans and colors, the
current lowercase-based approach is probably simplest and most consistent.
The larger issue, in my view, is the addition of `commons-lang3` as a
dependency just to call:
StringUtils.toRootLowerCase()
SystemProperties.getJavaSpecificationVersion()
Both have a single call site. I don’t think that justifies a helper
method, let alone pulling in a ~700 KiB dependency.
2. Other locales
If we want to support localized boolean and color values, both current
and proposed approaches have gaps:
- `String.equalsIgnoreCase()` can detect that `"İ"` (Turkic capital I
with dot above) equals `"i"` by lowercasing the capital, and that
`"I"` equals `"ı"` (dotless I) by uppercasing the lowercase letter.
- `String.toUpperCase()` can detect that `"ß"` equals `"SS"` by
expanding a single character to multiple characters.
- `String.toLowerCase()` can not detect any edge case.
Neither method fully covers Unicode case-insensitive matching. For truly
correct locale-aware matching, we should be using `Collator`.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
