1 2 3 Previous Next 37 Replies Latest reply on Jan 24, 2007 2:46 AM by 807607

    Fundamental Question about int vs Integer

    807607
      I don't really understand what the difference is between using the "int" keyword and using the Integer type. I've come to realise that "int" cannot be null whereas Integer can be null but why isn't int just an Integer type? Like an alias of sorts. I realise this a fairly basic question but I'm sure I'm not the only one pondering this :)
        • 1. Re: Fundamental Question about int vs Integer
          807607
          int, double, long, float, char, byte, boolean and short are primitive types in Java.

          Because for a variety of reasons in an OO language you do sometimes want everything to be an Object there are wrapper Objects for primitives.

          Integer is the wrapper object for ints.
          • 2. Re: Fundamental Question about int vs Integer
            807607
            The basic answer is that int is a primitive, and Integer is a class. Integer is a wrapper for ints, meaning it was designed to allow you to conveniently use a primitive int where only objects were allowed. Java 5 has a feature called autoboxing that allows you to use them somewhat interchangably.
            • 3. Re: Fundamental Question about int vs Integer
              807607
              OK thanks, that clears that up then :) So would you say to use primitives where you don't specifically need to use the class?

              I have a habit of initializing all class members by explicitly assigning "null" to them when they are declared...
              • 4. Re: Fundamental Question about int vs Integer
                796440
                OK thanks, that clears that up then :) So would you
                say to use primitives where you don't specifically
                need to use the class?
                Primitives are smaller and faster than their respective wrapper classes. When you're just doing pure numerical or logical stuff, and you're not required to have an Object (as in a Collection, for example), go with the primtives.



                I have a habit of initializing all class members by
                explicitly assigning "null" to them when they are
                declared...
                Bad idea.

                For member variables, it's unnecessary, as reference members are always given a default of null anyway. For local variables, it can prevent the compiler from finding your logic errors, and they get pushed to runtime.

                Don't initialize any locals at declaration unless you know that that value can make sense and be used through at least one code path. The compiler errors you get that say, "...might not have been initialized" are a good thing. They're telling you that your logic is such that you might be trying to read a variable before you've set it. If you just initialize the local to make the compiler happy, you might be masking a logic error--for example, your if cases didn't cover every possibility. Sometimes it will turn out that it does make sense to initialize them at declaration, but if you're setting null or 0 or something just to make the compiler happy, that's a red flag.
                • 5. Re: Fundamental Question about int vs Integer
                  807607
                  In an ideal world there would be no ints. Everything would be an Integer so that all things in java were objects. The problem is, that the Integer class is immutable. Which means, that once you create an instance of one, it never will change values. So doing math with Integer objects is a matter of always creating new instance to hold results of calculations. So if Integer was the only thing that existed you would have to do
                  Integer a = new Integer(5);
                  Integer b = new Integer(6);
                  Integer c = new Integer(a.intvalue() + b.intValue());
                  This is both tedious, creates alot of garbage, and since doing math is relatively important thing, takes too much time. So the concept of a primitive was introduced to improve performance.

                  so

                  int a;

                  is not an object. You can't pass it to things that need objects, but it is useful for when you need to do math operations.

                  So the moral of the story is, use int if your requirements allow it, use Integer otherwise.
                  • 6. Re: Fundamental Question about int vs Integer
                    807607
                    Integer a = new Integer(5);
                    Integer b = new Integer(6);
                    Integer c = new Integer(a.intvalue() +
                    b.intValue());
                    That is still using primitives, though. They would need to let you be able to do something like this:
                    Integer a = new Integer(5);
                    Integer b = new Integer(6);
                    Integer c = a.add(b);
                    Very awkward.
                    • 7. Re: Fundamental Question about int vs Integer
                      796440
                      In an ideal world there would be no ints.
                      Why would that be ideal?
                      • 8. Re: Fundamental Question about int vs Integer
                        807607
                        In an ideal world there would be no ints.
                        Why would that be ideal?
                        Maybe he meant something like "if java was completely OO."
                        • 9. Re: Fundamental Question about int vs Integer
                          807607
                          In an ideal world there would be no ints.
                          Why would that be ideal?
                          I meant from an OO point of view. I believe that is what SmallTalk does.
                          • 10. Re: Fundamental Question about int vs Integer
                            807607
                            They would
                            need to let you be able to do something like this:
                            Integer a = new Integer(5);
                            Integer b = new Integer(6);
                            Integer c = a.add(b);
                            Very awkward.
                            Yes, that's what i should have written. thanks.
                            • 11. Re: Fundamental Question about int vs Integer
                              796440
                              In an ideal world there would be no ints.
                              Why would that be ideal?
                              I meant from an OO point of view. I believe that is
                              what SmallTalk does.
                              I see.

                              Yeah, it would be more "pure OO," by most definitions of that term. That doesn't necessarily make it "better" though, and I took your ideal world comment to mean that it would be "better."
                              • 12. Re: Fundamental Question about int vs Integer
                                807607
                                In an ideal world there would be no ints.
                                Why would that be ideal?
                                Or better yet, no ints or Integer just BigInteger and BigDecimal. Or, even better than that maybe, just Big

                                :)
                                • 13. Re: Fundamental Question about int vs Integer
                                  807607
                                  I'm not sure if the autoboxing stuff in 1.5 affects this at all or not, but one key difference between objects and primitives is that primitives get passed by value, whereas objects are passed by reference.
                                  • 14. Re: Fundamental Question about int vs Integer
                                    807607
                                    I'm not sure if the autoboxing stuff in 1.5 affects
                                    this at all or not, but one key difference between
                                    objects and primitives is that primitives get passed
                                    by value, whereas objects are passed by reference.
                                    NOOOOOOOOOOOOOO!

                                    Wrong. Wrong. Wrong. Wrong. Wrong.

                                    Everything in Java is passed "by value". Everything.

                                    Pass-by-value
                                    - When an argument is passed to a function, the invoked function gets a copy of the original value.
                                    - The local variable inside the method declaration is not connected to the caller's argument; any changes made to the values of the local variables inside the body of the method will have no effect on the values of the arguments in the method call.
                                    - If the copied value in the local variable happens to be a reference (or "pointer") to an object, the variable can be used to modify the object to which the reference points.

                                    Some people will say incorrectly that objects are passed "by reference." In programming language design, the term pass by reference properly means that when an argument is passed to a function, the invoked function gets a reference to the original value, not a copy of its value. If the function modifies its parameter, the value in the calling code will be changed because the argument and parameter use the same slot in memory.... The Java programming language does not pass objects by reference; it passes object references by value. Because two copies of the same reference refer to the same actual object, changes made through one reference variable are visible through the other. There is exactly one parameter passing mode -- pass by value -- and that helps keep things simple.
                                    -- James Gosling, et al., The Java Programming Language, 4th Edition
                                    1 2 3 Previous Next