Less rigorous description of autoboxing?

[Miles Jiang]

OCP Java SE11 Programmer I Study Guide, Page 201, Penultimate paragraph.

When discussing autoboxing into Integer, an example is given:

List<Integer> numbers = new ArrayList<>();
numbers.add(1);
numbers.add(2);
numbers.remove(1);
System.out.println(numbers); // [1] (not desired result)

We want to remove the element 1 but the statement at Line 4 actually removes the element at index 1, which is 2, so what remains is 1 instead of 2. To get the desired result, the book recommend that Line 4 be replaced with numbers.remove(new Integer(1)).

This is one solution, but strictly speaking, Integer(int) has been deprecated since Java 9. So for the sake of rigor, it seems better to use numbers.remove(Integer.valueOf(1)), I guess?

An online compiler like Techie Delight accepts new Integer(1) without any problem, while an IDE like Eclipse will tell you that "The constructor Integer(int) is deprecated since version 9" and provide two quick fixes; one of which is adding @SuppressWarnings "deprecation" to main(). Of course, an IDE also accepts new Integer(1).

[Mikalai Zaikin]

And the reason for deprecating new Integer is because Java API caches Integers from -128 to 127 range by default (for the cases of autoboxing, to avoid repeating same most often used instances), and new keyword always makes the new object on the Heap.
So, there is no way to control new Integer(1); new Integer(1);-- these will be different references, and == will give false.
While Factory Method is a nice way to control instances creation and cache as needed.
So, surely Integer.valueOf(1) must be used.

    public static void main(String[] args) {
        System.out.println(new Integer(1) == new Integer(1));
        System.out.println(Integer.valueOf(1) == Integer.valueOf(1));
    }

false
true

[Jesse Silverman]

There are so many things in Java because of its history and steadfast commitment to (almost) never break old code.

Continuing to allow

new Integer(myValue)

instead of

Integer.valueOf(myValue)

is notable but not nearly the worst.  If the code gets called tons you will waste a little bit of memory.

The fact that you can make an ArrayList containing stray dogs, favorite bookmarks, phone numbers, dangerous drugs, your grades from school and your Grandma's best friends, despite the fact that most sane people think you never should do that...and that arguably you can do so because generics are a "New Feature" from 2004 that we don't want to force people to adopt in slow-changing code...seems to be a much more serious issue to me.

There are courses and other material still "out there" by people who are reasonably highly respected and arguably quite skillful, that go thru the entire Java Collections Framework only showing generics in the few places absolutely needed (or maybe nowhere, but avoiding storing heterogeneous objects only in those cases) and then presenting Generics as a "new feature" right at the end...

I understand why Oracle doesn't want to break old code, but that is not necessarily an excuse for others to teach people to write Java like it is 2003...I agree with the OP and the reply, and am grateful that these book authors very rarely show bad old ways to do things, if they do it is in service of preparing test takers for something they might see on the exam.

[Miles Jiang]

Thanks your explanation @Mikalai and @Jesse. Now I got the point.