I have added a comment that there’s a fix in your bleeding edge code.

This class was written when we still have supported java 1.4 and because java 1.4 has not supported this feature (java.lang.Integer.valueOf(int):Integer) we had to do on our own, we have selected the range from 0 to 100, because most number used inside the most popular application are in this range, before we have selected this range we have add a logger to the method Constants.Integer and then we have logged the numbers used while running different apps. in theory the jre implementation is better but in the real world it makes no difference and the railo impl use less memory.

the usage of objects from type Integer is very rare in Railo, because all numbers defined in the cfml code are handled as Double Object, Integer are mostly used for invoking for 3party libs.

“Moreover since the method is part of the API it’ll likely get compiled to native code much faster.”
classes like java.lang.Integer are in a regular jar archive, there is no difference between them and classes written by me or you, they are not faster, they work exact the same way. most (or even all today) JRE have a runtime compiler that translate the os indepedned bytecode to machine code at runtime.

“Trust the API: It is Faster!”
Newer trust a api that you not have written by yourself ;-)
the JRE library is very good but also the people at Sun are not perfect, new ideas only come in the field when there is a need for, not in the labs.

for example railo has it’s own floating number parser, simply because it is faster than the jre parser in 99% (or more) of all the cases used in railo. railo has it’s own color definition parser, simply because it is more flexible than the jre color parser. we are on the way from switiching from JRE Date Handling to Joda (see classes railo.commons.date.JREDateTimeUtil, railo.commons.date.JodaDateTimeUtil) simply because joda is faster/better.
and all this are only things i have in mind at the moment.

but like sun we are more than open for suggestions to improve our current code base, but defintily no api or app is perfect and need no improvement.

/micha

p.s. sorry my bad english need improvment as well ;-)

The presentation slides and the code are already linked from the presentation pages. Perhaps you missed it? :)

Thank you!

I asked the same question recently of someone at Adobe and they said that the tracker unfortunately hides bugs that are marked as “targeted for a future release”. I suppose this is to hide bugs about unreleased versions of CF (ex. CF10).

I think the bugs will reappear once the hot fix is released.