commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <>
Subject Re: [LANG] unnecessary boxing in StringEscapeUtils etc.
Date Sun, 19 Jun 2011 16:03:48 GMT
On Thu, May 19, 2011 at 5:14 AM, Stephen Colebourne
<> wrote:
> I doubt that the boxing will be a major performance problem. Moreover,
> its one that will have to be solved for JDK 8 anyway (as Project
> Lambda needs some kind of solution to enhance primitive/object
> operations).

I'd prefer to see this left alone.  As Hen mentions on another thread,
this isn't the biggest part of the lang APIs, and the consistency of a
single Range type is appealing, especially if autoboxing woes are
slated to be ameliorated in the not-too-distant future.

HOWEVER, if we prefer to have the ability to optimize around these
autoboxing complaints, why don't we add a level of inheritance to the
CodePointTranslator taxonomy, wherein we place the "is this an
applicable codepoint" check and delegate that to another interface?
Now a specialized IntRange can be supplied after all, and can use a
corresponding "CodepointInclusionPredicate" implementation to make the
proper call.  Optimizable, but works out of the box using autoboxing.

> If the cast is a problem, why not have four versions of the operation
> - Integer, Char, int and char?
> That means that any optimisation for primitives can be handled
> internally in a non-breaking way at a later date.

Sounds reasonable.


> Stephen
> On 19 May 2011 05:47, Henri Yandell <> wrote:
>> *grumbles that they were ints and a previous RC candidate saw it
>> change to Range* :)
>> My bigger complaint is the explicit casting required to pass in chars:
>>    new UnicodeEscaper(Range.between(0, (int)'E')) ?
>> Autoboxing doesn't seem to be able to turn a char into an Integer.
>> Hen
>> On Wed, May 18, 2011 at 6:53 AM, sebb <> wrote:
>>> I'm not happy with the boxing that is often needed to create a Range
>>> of int or long, e.g. in StringEscapeUtils.
>>> Seems to me that the UnicodeEscaper and NumericEntityEscaper classes
>>> should require ints rather than a Range, as this would cut down on the
>>> boxing and unboxing that is currently needed, as well as the extra
>>> code needed to provide comparisons etc.
>>> Or, there could be a specialised IntRange class using int to provide
>>> the functionality.
>>> These changes are new to 3.0, so could be fixed now without backward
>>> compat. problems.
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

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

View raw message