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}.
