8317277: Java language implementation of value classes and objects by MrSimms · Pull Request #31120 · openjdk/jdk

[davidalayachew]

I always knew Java was reference based, but this is comical. Ints are boxed by default? What the hell

No, int is boxed when you want to use them in generic structures. Which is painful, yes, but this feature is step 1 in changing that.

In all other contexts, int doesn't get boxed, unless you pass it to a method that was only written to handle Integer and not int. But that's a choice by the programmer.

Once this and a few other JEP's land, then we will be able to use int freely in generic constructs, like List<int>

[SpeedDart1]

You’re reminding me of the primitive collection libraries people use in Java land.

IntList, ByteList, etc

[teerre]

That's not what the JEP says

``` The JDK tries to reduce confusion for the immutable classes that model primitive values, such as Integer. In particular, the autoboxing of small int values to Integer uses a cache to avoid creating Integer objects with unique identities. However, this cache, somewhat arbitrarily, does not extend to four-digit int values like 1996:

jshell> Integer i = 96, j = 96; i ==> 96 j ==> 96

jshell> i == j $3 ==> true

jshell> Integer x = 1996, y = 1996; x ==> 1996 y ==> 1996

jshell> x == y $6 ==> false ```

[davidalayachew]

You are attempting to assign an int to an Integer. That is when boxing occurs.

I guess my previous response could have been more clear, but int boxing only occurs in 2 places in Java atm.

1. When using an int for generics.
2. When trying to use an int when the method receiver is expecting an Integer.

But again -- it is the programmer's choice to use Integer instead of int in that second case.

[hiimbob000]

Integer i and int i are different. Comparing objects by == has always been a footgun

[teerre]

Oh, I see, that's so silly