JDK-8176335 : Release Note: Deprecation of Boxed Primitive Constructors
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 9
  • Priority: P3
  • Status: Closed
  • Resolution: Delivered
  • Submitted: 2017-03-08
  • Updated: 2017-09-22
  • Resolved: 2017-03-14
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 9
9Resolved
Related Reports
Relates :  
Description
Classes `Boolean`, `Byte`, `Short`, `Character`, `Integer`, `Long`, `Float`, and `Double` are "box" classes that correspond to primitive types. The constructors of these classes have been deprecated.

Given a value of the corresponding primitive type, it is generally unnecessary to construct new instances of these box classes. The recommended alternatives to construction are autoboxing or the `valueOf` static factory methods. In most cases, autoboxing will work, so an expression whose type is a primitive can be used in locations where a box class is required. This is covered in the *Java Language Specification*, section 5.1.7, "Boxing Conversion." For example, given `List<Integer> intList`, the code to add an `Integer` might be as follows: 
```
    intList.add(new Integer(347));
```
This can be replaced with:
```
    intList.add(347);
```
Autoboxing should not be used in places where it might affect overload resolution. For example, there are two overloads of the `List.remove` method:
```
    List.remove(int i)        // removes the element at index i
    List.remove(Object obj)   // removes an element equal to obj
```
The code to remove the `Integer` value 347 might be as follows:
```
    intList.remove(new Integer(347));
```
If this code is changed in an attempt to use autoboxing:
```
    intList.remove(347);
```
This will not remove the `Integer` value 347, but instead it will resolve to the other overloaded method, and it will attempt to remove the element at index 347.

Autoboxing cannot be used in such cases. Instead, code should be changed to use the `valueOf` static factory method:
```
    intList.remove(Integer.valueOf(347));
```

Autoboxing is preferable from a readability standpoint, but a safer transformation is to replace calls to the box constructors with calls to the `valueOf` static factory method.

Using autoboxing or the `valueOf` method reduces memory footprint compared to the constructors, as the integral box types will generally cache and reuse instances corresponding to small values. The special case of `Boolean` has static fields for the two cached instances, namely `Boolean.FALSE` and `Boolean.TRUE`.

With the exception of `Character`, the box classes also have constructors that take a `String` argument. These parse and convert the string value and return a new instance of the box class. A `valueOf` overload taking a `String` is the equivalent static factory method for this constructor. Usually it's preferable to call one of the `parse` methods (`Integer.parseInt`, `Double.parseDouble`, etc.) which convert the string and return primitive values instead of boxed instances.

Comments
This Release Note subtask is actually a note for JDK-8145468, which is itself a subtask, so it cannot have subtasks of its own.
08-03-2017