Java Integer vs. String Autoboxing Design

Question

In Java, I can do the following to succinctly guard against a NullPointerException:

if ("myString".equals(someOtherString))

But I cannot do the same with Integers, e.g.

if (5.equals(someOtherInteger))

I get a compile-time error. Any ideas on why this design decision was made? Or any resources that might explain it? Thanks in advance.

EDIT: someOtherInteger is an Integer, not an int.

An `Integer` is an object. An `int` is a primitive type, like `int`s in C. So, it doesn't have the `.equals()` method, which is inherited from `Object`. — , Apr 17 '12 at 03:30
@Travis So, your question is why doesn't the Java language offer syntactic sugar that would allow the automatic autoboxing of a primitive integer when you apply the dot (.) operator so that you could simply write this Yodah-type predicate? Am I getting this right? — Edwin Dalorzo, Apr 17 '12 at 03:35
@edalorzo You got it. The answer from trutheality offers the most insight of any of the answers so far. — Travis Webb, Apr 17 '12 at 03:38
@Travis my good colleague, there are a million things I wonder why Java doesn't do. And I pretty much think the answer is simply because that's the way it is. The Internet is full with good ideas of how to improve Java, but they all cost time and money and human resources, and so, they are invested where they are more important. I do not think there is any official documentation of why this is not implemented, but we could certainly add it to the long list of good ideas, if it is not already there. — Edwin Dalorzo, Apr 17 '12 at 03:42
@edalorzo This is not a feature request, it's simply a question. And, Jeffrey just furnished some documentation that you claim doesn't exist. — Travis Webb, Apr 17 '12 at 03:44
@Travis your question is why you can't do this, Jefrry's answer is about what you can indeed do. As such, it offers no explanation whatsoever regarding why it was not implemented in Java, from my point of view. But hey, it's your question. If you are satisfied with that answer... — Edwin Dalorzo, Apr 17 '12 at 03:49

trutheality · Answer 1 · 2012-04-17T03:53:04.450

String has always been an object in Java. There is no autoboxing for strings, and there can't be in principle. Autoboxing from the primitive int to the Integer object has been introduced fairly recently.

It is valid to ask why trying to access member variables of primitives doesn't invoke autoboxing (95.toString(radix) would actually be pretty convenient), but I imagine that the reason is that it wasn't considered a likely use-case, since since almost every wrappedPrimitive.method() has an equivalent WrapperClass.method( primitive ) version.

equals() is usually unnecessary for primitive types since == is already there. However, you do make a good case for it as a null-guard... 5 == integerInstance will try to unbox the instance, and throw a NullPointerException if the instance is null, unfortunately. (I didn't fully appreciate your point at first.)

That said, it would be really cool if we could hear from someone working on Java either currently or at the introduction of autoboxing about whether they considered this sort of functionality.

Thank you for actually reading my question and providing an insightful response. — Travis Webb, Apr 17 '12 at 03:36

score 10 · Accepted Answer · edited Jun 20 '20 at 09:12

The JLS specifies that boxing conversions can only occur during assignment conversions, method invocation conversions, or casting conversions. Since you are neither assigning 5 to a variable, passing it as an argument to a method, nor explicitly casting it to Integer, it will not be autoboxed for you.

Assignment conversion (§5.2, §15.26) converts the type of an expression to the type of a specified variable.

Assignment conversion may cause an OutOfMemoryError (as a result of boxing conversion (§5.1.7)), a NullPointerException (as a result of unboxing conversion (§5.1.8)), or a ClassCastException (as a result of an unchecked conversion (§5.1.9)) to be thrown at run-time.

Method invocation conversion (§5.3, §15.9, §15.12) is applied to each argument in a method or constructor invocation and, except in one case, performs the same conversions that assignment conversion does.

Method invocation conversion may cause an OutOfMemoryError (as a result of boxing conversion (§5.1.7)), a NullPointerException (as a result of unboxing conversion (§5.1.8)), or a ClassCastException (as a result of an unchecked conversion (§5.1.9)) to be thrown at run-time.

Casting contexts allow the use of one of:

...

a boxing conversion (§5.1.7) optionally followed by a widening reference conversion (§5.1.5)

@TravisWebb Oops, I forgot about casting conversions. Added that in too. — Jeffrey, Apr 17 '12 at 03:51

score 1 · Answer 3 · answered Apr 17 '12 at 03:26

1

you can use

if (someOtherInteger!=null && someOtherInteger == 5)

answered Apr 17 '12 at 03:26

turbanoff

2,439
6
42
99

2

If `someOtherInteger` is `null`, you will get a `NullPointerException` (assuming that it is an `Integer`). – Jeffrey Apr 17 '12 at 03:28
Except it's well-documented that `==` != `.equals()` – Travis Webb Apr 17 '12 at 03:28
@TravisWebb in the case of primitives, which do not have any methods, it is. – Jeffrey Apr 17 '12 at 03:29
`Integer` is not a primitive. – Travis Webb Apr 17 '12 at 03:29
Yes, there really needs checking for null. – turbanoff Apr 17 '12 at 03:29
@Jeffrey As you can see above the OP is using primitives not Integers – Hunter McMillen Apr 17 '12 at 03:29
@twain249 See the following thread for why you're completely wrong: http://www.coderanch.com/t/409507/java/java/Difference-between-equals – Travis Webb Apr 17 '12 at 03:30
@HunterMcMillen Then why is he trying to guard against a `NullPointerException`? He stated he is working with `Integer`s. – Jeffrey Apr 17 '12 at 03:30
The numeric literal `5` is _not_ an Integer. Whether `someOtherInteger` is or is not an Integer is irrelevant because you _cannot_ call methods on a primitive. – Hunter McMillen Apr 17 '12 at 03:31
@TravisWebb so you want to compare an `Integer` to an `int` then you can just create an `Integer` for the `int` and compare it `if(new Integer(5).equals(someOtherInteger)` – twain249 Apr 17 '12 at 03:32
@HunterMcMillen thank you for pointing out the obvious. My question is, why doesn't Java autobox it vis a vis `Integer x = 5;` – Travis Webb Apr 17 '12 at 03:32
@twain249 yes but I don't have to do that for `String` e.g. `new String("myString").equals(...)`, I can just say `"myString".equals` – Travis Webb Apr 17 '12 at 03:33
Autoboxing usually occurs when you pass values to methods, when you explicitly try to dereference a value that is a primitive you will always get an error. – Hunter McMillen Apr 17 '12 at 03:33
@twain249 `new Integer(5) == 5` will return `true`. It makes sense to compare to an `int` like this in this scenario. – Jeffrey Apr 17 '12 at 03:34

score 1 · Answer 4 · answered Apr 17 '12 at 03:39

I suspect that autoboxing is not implemented for the literal 5, whereas it is for a string myString, as a safety measure. It's safe to autobox a syntactic structure that is prepended and appended with double quotation marks "", because it's unlikely that the quotation marks are unintended, so the user's intention is clear and type-safety is not compromised.

However, the literal 5 could be a typo on the user's part - or it could be intended to be a string, rather than an integer. Therefore, to maintain the benefit that variables must be declared before use in object-oriented programming in order to prevent typos (among many other advantages) (even if it's implicit, as in the case of autoboxing), 5 is not autoboxed.

score 0 · Answer 5 · edited May 23 '17 at 10:30

0

int is a primitive type it doesn't support any methods itself. To compare 2 ints you simply use the == convention as in:

if(a == b)

There is an Integer class that is a wrapper for an int that supports some other method calls

Edit:

Based on your edit you want to compare to Integer but the problem is the literal 5 isn't an Integer you have to create a new integer for it.

Integer myInt = 5;
if(myInt.equals(someOtherInteger)) ...

This design is inherent in the fact that primitives don't have any methods. As to whether primitives should support methods (or simply not exist) is integral to the debate as to whether Java is a Pure Object Oriented Language or not (many say no due to the fact that primitives exist).

edited May 23 '17 at 10:30

Community

1
1

answered Apr 17 '12 at 03:28

twain249

5,666
1
21
26

I didn't realize that I needed to clarify my question by adding "I'm not a complete idiot", but I will. This is not what I'm looking for. – Travis Webb Apr 17 '12 at 03:29
What are you asking then. primitives don't have methods. – twain249 Apr 17 '12 at 03:30

score 0 · Answer 6 · answered Apr 17 '12 at 03:31

Here is a bit of reading on the different comparisons: http://www.leepoint.net/notes-java/data/expressions/22compareobjects.html

Not sure if it was a built in design to reject int

If you do

Integer s=5;
Integer d=5;
if(d.equals(s)){
    System.out.println("Fun");
}

It works just fine.

Java Integer vs. String Autoboxing Design

6 Answers6