JDK 11 RFR of 8200478: For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc

[David Holmes]

Hi Joe,

On 25/04/2018 10:30 AM, joe darcy wrote:
> Hello,
> 
> Please review the patch below to update the specification of 
> Long.valueOf(long) to require caching on [-128, 127]. The JDK 
> implementation of this functionality has always cached in that region, 
> even though it is not required.

Seems very explicit that there is no requirement for Long to do caching. 
So why should that change? Or put another way what has changed that 
invalidates that clearly stated position?

Thanks,
David

> Additionally, please review the corresponding CSR:
> 
>          JDK-8202231: For boxing conversion javac uses Long.valueOf 
> which does not guarantee caching according to its javadoc
> 
> Thanks,
> 
> -Joe
> 
> diff -r f909f09569ca src/java.base/share/classes/java/lang/Long.java
> --- a/src/java.base/share/classes/java/lang/Long.java    Wed Apr 18 
> 21:10:09 2018 -0700
> +++ b/src/java.base/share/classes/java/lang/Long.java    Tue Apr 24 
> 17:25:24 2018 -0700
> @@ -1164,10 +1164,8 @@
>        * significantly better space and time performance by caching
>        * frequently requested values.
>        *
> -     * Note that unlike the {@linkplain Integer#valueOf(int)
> -     * corresponding method} in the {@code Integer} class, this method
> -     * is <em>not</em> required to cache values within a particular
> -     * range.
> +     * This method will always cache values in the range -128 to 127,
> +     * inclusive, and may cache other values outside of this range.
>        *
>        * @param  l a long value.
>        * @return a {@code Long} instance representing {@code l}.
>