JDK-8200478 : For boxing conversion javac uses Long.valueOf which does not guarantee caching according to its javadoc
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 9,10,11
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • CPU: generic
  • Submitted: 2018-03-29
  • Updated: 2018-07-12
  • Resolved: 2018-04-26
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 11
11 b12Fixed
Related Reports
CSR :  
Relates :  
Description
FULL PRODUCT VERSION :
Since JDK 9.

ADDITIONAL OS VERSION INFORMATION :
Unrelated to OS.

A DESCRIPTION OF THE PROBLEM :
public class Temp {
	public static void main(String[] args) {
		final Long a = 121L;
		System.out.println(a);
	}
}

javap -v Temp (partial result)
         0: ldc2_w        #2                  // long 121l
         3: invokestatic  #4                  // Method java/lang/Long.valueOf:(J)Ljava/lang/Long;

Compiling this code reveals that the class generated by javac uses Long.valueOf(121L).

JLS 9 in 5.1.7. Boxing Conversion says (this part was changed in this version of JLS):
"If the value p being boxed is the result of evaluating a constant expression (��15.28) of type boolean, char, short, int, or long, and the result is true, false, a character in the range '\u0000' to '\u007f' inclusive, or an integer in the range -128 to 127 inclusive, then let a and b be the results of any two boxing conversions of p. It is always the case that a == b."
so the  value 121L should always be cached.

However, javadoc for Long.valueOf(long) says:
" Note that unlike the corresponding method in the Integer class, this method is not required to cache values within a particular range."

This is a bug for javac to use a method which does not guarantee caching where the value MUST be cached according to JLS.

It is a bug either in javac or a wrong documentation of Long.valueOf(long)


REGRESSION.  Last worked in version 8u172

ADDITIONAL REGRESSION INFORMATION: 
JLS was changed between version 8 and 9.
Under JLS 8 it was not required to cache Longs so this was not a bug.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
As in the description.

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
A method that guarantees caching is used for boxing conversion of longs.

More practical solution: adjust javdoc of Long.valueOf(long) to say it guarantee caching.
ACTUAL -
As in the description.

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
public class Temp {
	public static void main(String[] args) {
		final Long a = 121L;
		System.out.println(a);
	}
}

---------- END SOURCE ----------


Comments
Review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-April/052741.html
25-04-2018

While the spec of Long.valueOf doesn't require it to cache, it has long actually done caching over [-128, 127] and the spec can be updated to require this behavior.
24-04-2018

This looks like issue to me, JLS changed in 9 and javadoc was not updated accordingly. Implementation is according to javadoc. There should be 2 changes are required here. 1. Update javadoc according to spec 2. Update implementation according to updated javadoc
30-03-2018