8252827: Caching Integer.toString just like Integer.valueOf

David Holmes david.holmes at oracle.com
Sat Apr 17 05:07:35 UTC 2021

On 17/04/2021 4:54 am, Raffaello Giulietti wrote:
> I guess the reporter meant to limit the cache range similarly to the one 
> used for valueOf().
> I have no clue about the benefit/cost ratio for the proposed String 
> cache. It really depends on usage, workload, etc. One can easily imagine 
> both extreme scenarios but it's hard to tell how the average one would 
> look.
> My post is only about either solving the issue by implementing the 
> cache, which I can contribute to; or closing it because of lack of 
> real-world need or interest.

Caching for the sake of caching is not an objective in itself. Unless 
the caching can be shown to solve a real problem, and the strategy for 
managing the cache is well-defined, then I would just close the 
enhancement request. (Historically whether an issue we don't have any 
firm plans to address is just left open "forever" or closed, depends 
very much on who does the bug triaging in that area. :) )


> Greetings
> Raffaello
> On 2021-04-16 20:36, Roger Riggs wrote:
>> Hi,
>> Is there any way to quantify the savings?
>> And what technique can be applied to limit the size of the cache.
>> The size of the small integer cache is somewhat arbitrary.
>> Regards, Roger
>> On 4/16/21 12:48 PM, Raffaello Giulietti wrote:
>>> Hello,
>>> does the enhancement proposed in [1] make sense, both today and when 
>>> wrappers will be migrated to primitive classes?
>>> If so, it should be rather simple to add it and I could prepare a PR.
>>> If not, the issue might perhaps be closed.
>>> Greetings
>>> Raffaello
>>> ----
>>> [1] https://bugs.openjdk.java.net/browse/JDK-8252827

More information about the core-libs-dev mailing list