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).
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. Stephen On 19 May 2011 05:47, Henri Yandell <flame...@gmail.com> 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 <seb...@gmail.com> 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: 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
