Skip to Main Content

Java Programming

Announcement

For appeals, questions and feedback about Oracle Forums, please email oracle-forums-moderators_us@oracle.com. Technical questions should be asked in the appropriate category. Thank you!

Interested in getting your voice heard by members of the Developer Marketing team at Oracle? Check out this post for AppDev or this post for AI focus group information.

operator == cannot be applied to int,java.lang.Integer

807607Jan 8 2007 — edited Jan 10 2007
import java.util.ArrayList;
public class intObject
{
public static void main(String [] args)
{
// Create the ArrayList 5 7 3 4 9
// Produce the output below through appropriate method calls
// ==================================
// The ArrayList contains 5 7 3 4 9
// The location of 5 is 0
// The max is 9
// The min is 3
// The sum is 28
// The average is 5.6
// After adding 1 in location 2 and
// removing values in locations 4 and 0,
// The ArrayList contains 7 1 3 9
// The location of 5 is -1
// The max is 9
// The min is 1
// The sum is 20
// The average is 5.0
ArrayList list = new ArrayList();
list.add( new Integer(5) );
list.add( new Integer(7) );
list.add( new Integer(3) );
list.add( new Integer(4) );
list.add( new Integer(9) );
System.out.print("The ArrayList contains ");
display(list);
System.out.println("The location of 5 is " + search(list, 5) );
//System.out.println("The max is " + max(list) );
//System.out.println("The min is " + min(list) );
System.out.println("The sum is " + sum(list) );
/*System.out.println("The average is " + average(list) );
list.add( 2, new Integer(1) );
list.remove(4);
// NOTE: ArrayList objects can be dynamically resized
list.remove(0);
System.out.print("The ArrayList contains ");
display(list);
System.out.println("The location of 5 is " + search(list, 5) );
System.out.println("The max is " + max(list) );
System.out.println("The min is " + min(list) );
System.out.println("The sum is " + sum(list) );
System.out.println("The average is " + average(list) );*/
}
private ArrayList ar= new ArrayList();

public static void display(ArrayList ar)
{
for(int i=0;i<ar.size();i++)
{
System.out.println(ar.get(i));
}
}

public static int sum(ArrayList ar)
{
int sum=0;
for(int i =0; i<ar.size();i++)
{
Integer x = (Integer)ar.get(i);
sum += x.intValue();
}
return sum;
}

public static int search(ArrayList ar, int num )
{
int location=0;
for (int i = 0; i< ar.size(); i++)
{
if(num==((Integer)ar.get(i)))
{
location=i;
}
}return location;
}

public static int max(ArrayList ar)
{
int greatest = 0;
for(int i =0; i <ar.size();i++)
{
if(greatest<(Integer)ar.get(i))
greatest=(Integer)ar.get(i);
}return greatest;
}

public static int min(ArrayList ar)
{
int smallest = 99999999;
for(int i =0; i <ar.size(); i++)
{
if(smallest>(Integer)ar.get(i))
smallest=(Integer)ar.get(i);
}return smallest;
}
}

I never got these errors while i was using the school computer but when I tried doing the program at home i got a whole bunch of errors.
public static int search(ArrayList ar, int num )
{
int location=0;
for (int i = 0; i< ar.size(); i++)
{
if(num==((Integer)ar.get(i)))//operator == cannot be applied to int,java.lang.Integer
{
location=i;
}
}return location;
}

public static int max(ArrayList ar)
{
int greatest = 0;
for(int i =0; i <ar.size();i++)
{
if(greatest<(Integer)ar.get(i))//operator == cannot be applied to int,java.lang.Integer
greatest=(Integer)ar.get(i);
}return greatest;
}

can someone explain to me what's wrong with these problems?

Comments

807607
Integer is a class, int is a primitive. They are not the same thing.
796254
The error message says it all:

if(num==((Integer)ar.get(i)))//operator == cannot be applied to int,java.lang.Integer

num is an int; the other an Integer object. You can't compare the two like this. They're different types.

I'd recommend that you get the int value out of the Integer:
if (num == ((Integer)ar.get()).intValue())
{
}
%
800323
You are trying to compare an int to an Integer.
An int is a primitive while an Integer is an object (wrapper class for int).

Use:
if (myInt == myInteger.intValue()) {
. . . 
}
Note: autoboxing in Java 5.0 should allow you to compare the two and do the conversion implicitly but I have not used it enough to know the details.

Message was edited by:
jbish
Fixed spelling.
807607
if(num==((Integer)ar.get(i)).intValue())
807607
thanks, i remember my teacher talking about that but i didnt use it for that part b/c it worked while in class. guess it doesnt on my computer
807607
it worked in class? You mean on a piece of paper in your notepad? Hate to burst your bubble but your notepad is most likely not equipped with a java compiler.
thanks, i remember my teacher talking about that but
i didnt use it for that part b/c it worked while in
class. guess it doesnt on my computer
807607
thanks, i remember my teacher talking about that but
i didnt use it for that part b/c it worked while in
class. guess it doesnt on my computer
Probably because they have version 1.5 at your school which has autoboxing.
807607
Yeah. Using '==' won't be a problem if you have the latest stable version of Java. (1.5.0), but with older versions, wrapper classes aren't automatically boxed and unboxed.
800323
Yeah. Using '==' won't be a problem if you have the
latest stable version of Java. (1.5.0), but with
older versions, wrapper classes aren't automatically
boxed and unboxed.
My 2 cents:
I am not so sure I like the autoboxing feature - it has the potential to hide bugs at compile time and explicit casting can help show the intent of the code.
int myInt = 0;
Integer myInteger = new Integer(10);
. . .
myInteger = 1;  // Oops; but still compiles
Not tested by derived from some code I saw earlier on the forum.
There was also some code I saw in one of the articles that showed a worse example but I cannot remeber what or where.
807607
The purpose of autoboxing was to free us from having to worry about when to use a wrapper object instead of a primitive, and from having to do explicit conversions and casts all the time. As a rule of thumb, if you're running JDK 5+, the names of the wrapper classes (Integer, Boolean, etc.) should not appear anywhere in your code except in type parameters (unless you're calling methods on them, like Character.isLetter() or Integer.toHexString()). Here's how the OP's code looks when that rule is applied:
import java.util.ArrayList;
import java.util.List;

public class Test
{
  public static void main(String[] args)
  {
    List<Integer> list = new ArrayList<Integer>();
    list.add(5);
    list.add(7);
    list.add(3);
    list.add(4);
    list.add(9);
    System.out.print("The ArrayList contains ");
    display(list);
    System.out.println("The location of 5 is " + search(list, 5));
    System.out.println("The max is " + max(list) );
    System.out.println("The min is " + min(list) );
    System.out.println("The sum is " + sum(list));
  }

  public static void display(List<Integer> ar)
  {
    for (int i = 0; i < ar.size(); i++)
    {
      System.out.println(ar.get(i));
    }
  }

  public static int sum(List<Integer> ar)
  {
    int sum = 0;
    for (int i = 0; i < ar.size(); i++)
    {
      sum += ar.get(i);
    }
    return sum;
  }

  public static int search(List<Integer> ar, int num)
  {
    int location = 0;
    for (int i = 0; i < ar.size(); i++)
    {
      if (num == ar.get(i))
      {
        location = i;
      }
    }
    return location;
  }

  public static int max(List<Integer> ar)
  {
    int greatest = 0;
    for (int i = 0; i < ar.size(); i++)
    {
      if (greatest < ar.get(i))
      {
        greatest = ar.get(i);
      }
    }
    return greatest;
  }

  public static int min(List<Integer> ar)
  {
    int smallest = 99999999;
    for (int i = 0; i < ar.size(); i++)
    {
      if (smallest > ar.get(i))
      {
        smallest = ar.get(i);
      }
    }
    return smallest;
  }
}
800323
The purpose of autoboxing was to free us from having
to worry about when to use a wrapper object instead
of a primitive, and from having to do explicit
conversions and casts all the time. As a rule of
thumb, if you're running JDK 5+, the names of the
wrapper classes (Integer, Boolean, etc.) should not
appear anywhere in your code except in type
parameters (unless you're calling methods on them,
like Character.isLetter() or Integer.toHexString()).
Here's how the OP's code looks when that rule is
applied:
import java.util.ArrayList;
mport java.util.List;
Yeh, I know. And it does help when you are using generics and variable parameter lists. But it can be confusing when you are modifying a program that was originally written under 1.4.x and are now using 1.5.x. It has its uses but does hide some of the original strong typing in Java.
807607
I have got one confusion about autoboxing.
If some value greater than 127 would have been placed in the arraylist, then also the program would have worked fine!
as according to what I know about autoboxing it caches only values in the range of -128 to 127.

I came to know about autoboxing from the following thread.
http://forum.java.sun.com/thread.jspa?threadID=5118056
807607
Yes, thanks to autoboxing, integer values are now subject to the same kind of confusion we've always had to deal with when working with strings: although you should always use equals(), you can often get away with using == to compare them. With strings, we can just tell people never to use ==, but the autoboxing trap is more subtle. This is the simplest rule of thumb I've come up with for avoiding it: Declare your collections with the correct wrapper types, then use them as if they really contained primitives.
jwenting
I have got one confusion about autoboxing.
If some value greater than 127 would have been placed
in the arraylist, then also the program would have
worked fine!
as according to what I know about autoboxing it
caches only values in the range of -128 to 127.
That has nothing to do with autoboxing, but with performance optimisation.
And why should it "have worked"? Your code was flawed for pre-1.5 compilers where autoboxing doesn't exist.
1 - 14
Locked Post
New comments cannot be posted to this locked post.

Post Details

Locked on Feb 7 2007
Added on Jan 8 2007
14 comments
14,384 views