I investigated Java primitive types

Introduction

When I use Java at work, I often use equals for equivalence evaluation. When I was a newcomer, I heard that "Equivalent use equals!" However, this is a story of object types such as String type.

Here, I was worried about int / Integer and long / Long that have primitive types. The question came up, "Long type is an object type, so you can't compare using == normally?"

It's a simple question, so I tried to verify it.

Identifying patterns to be compared

The target is a Long type with a primitive type, and the comparison method uses only ==. It feels like specifying a Long type instance on the left side and a Long type on the right side in various ways. Also, a comparison between a long constant and a Long type. It may be unsatisfactory because it is just the pattern that I came up with quickly.

Let's verify! !!

The verification was confirmed by running the following method on Junit4. I think it doesn't depend on the version, but I used Java 8 just in case. Some have been verified under the premise that "Long type is an object type".

@Test
public void testEqualsMethod() {
	Long value1 = 100L;

	//Long type made by either method is evaluated as equivalent
	assertTrue(value1==100L);                   // (1)
	assertTrue(value1==Long.parseLong("100"));  // (2)
	assertTrue(value1==Long.valueOf("100"));    // (3)
	assertTrue(value1==Long.valueOf(100));      // (4)
	assertTrue(100L==Long.parseLong("100"));    // (5)
	assertTrue(100L==Long.valueOf(100));        // (6)

	Long value2 = value1;        //If the Long type is an object type
	++value2;　　　　　　　　　　　//If you change the value of value2, the value of value1 should also change....
	assertTrue(100L==value1);    //But value1 does not change
	assertTrue(101L==value2);    //value2 is firmly increased by 1
	assertTrue(value1!=value2);  //Of course the objects are different...Seems to be
}

Consideration

From the above test method, it was found that the equivalence evaluation can be performed using == when the Long type is generated by any method. However, the feeling of "Long type-> object type-> equals is equals" does not disappear ... It was also found that even if the Long type is assigned to another object, there is no behavior that the object type shares. In other words, the Long type is created as a different object when assigned to another variable.

This result can be said for similar Integer types. However, in the Double type and Float type, the evaluation was NG probably because valueOf () returned the object type in the test methods (3) and (4). (On the contrary, I wonder why Long type and Integer type became True by valueOf () ...)

The point to note when setting "xxx == Xxx.parseXxx ()" or "xxx == Xxx.valueOf ()" is whether it is an integer type or a decimal type. So, the table below shows whether or not they are equivalent.

In fact, (5) of the test method is a comparison between primitive types, and (1), (2), and (6) are equivalent comparisons of [primitive type] == [object type]. Therefore, it is possible that "Isn't it True?"

If this is left as it is, it will be dragged and dragged, so I would like to examine this question at another time. It's open once. .. ..

bonus

I also wanted to confirm the nature of autoboxing, so I experimented with the following test method. It's like preparing a method with an Object type argument and throwing various values into the method to see what kind of class it will be. (Verification environment: Java8, JUnit4)

@Test
public void testAutoBoxing() {
	//A class that just returns the class name of the argument
	class AutoBoxingTester {
		public String get(Object obj) {
			return obj.getClass().getName();
		}
	};
	AutoBoxingTester tester = new AutoBoxingTester();

	//I tried throwing in various values
	assertEquals(Integer.class.getName(), tester.get(100));
	assertEquals(Long.class.getName(), tester.get(100L));
	assertEquals(String.class.getName(), tester.get("str"));
	assertEquals(Float.class.getName(), tester.get(3.14f));
	assertEquals(Double.class.getName(), tester.get(6.0e23));
}