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

2018-04-25 Thread joe darcy 

Hi Jon,


On 4/25/2018 8:57 AM, Jonathan Gibbons wrote:


Joe,

While I note that the primary text has been modified to include long 
types, the italic comment that follows still ends with the following:


Notice that integer literals of type|long|are allowed, but not 
required, to be shared.


-- Jon




It would seem that text missed being deleted with the prior update ;-)

-Joe

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

2018-04-25 Thread Jonathan Gibbons 

Joe,

While I note that the primary text has been modified to include long 
types, the italic comment that follows still ends with the following:


Notice that integer literals of type|long|are allowed, but not required, 
to be shared.


-- Jon


On 4/25/18 8:18 AM, joe darcy wrote:

Hi David,

On 4/25/2018 5:08 AM, David Holmes wrote:

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?




JLS 9 changed the requirements on autobox caching going from Java SE 8 
to 9:


https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7

vs

https://docs.oracle.com/javase/specs/jls/se9/html/jls-5.html#jls-5.1.7

The Long.valueOf method is used to implement autoboxing and its 
caching spec wasn't updated accordingly at the time.


Cheers,

-Joe

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

2018-04-25 Thread joe darcy 

Hi David,

On 4/25/2018 5:08 AM, David Holmes wrote:

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?




JLS 9 changed the requirements on autobox caching going from Java SE 8 to 9:

https://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7

vs

https://docs.oracle.com/javase/specs/jls/se9/html/jls-5.html#jls-5.1.7

The Long.valueOf method is used to implement autoboxing and its caching 
spec wasn't updated accordingly at the time.


Cheers,

-Joe

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

2018-04-25 Thread 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 not 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}.

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

2018-04-24 Thread Brian Burkhalter 
Hi Joe,

On Apr 24, 2018, at 5:30 PM, joe darcy  wrote:

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

Looks fine.

> Additionally, please review the corresponding CSR:
> 
> JDK-8202231: For boxing conversion javac uses Long.valueOf which does 
> not guarantee caching according to its javadoc

Done.

Brian

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

2018-04-24 Thread joe darcy 

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.


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