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 :)
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.
> 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.
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.
> > 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.
>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.
> > > 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."
> 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
> 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.
Edit that right now before a fight breaks out!!!
> > 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.
>
> Edit that right now before a fight breaks out!!!
There is no fight to have. It is wrong. End of story.
> 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.
No.
Primitives are passed by value.
References are passed by value.
Null is passed by value.
Objects are not passed by reference. Passing references by value bears a surface similarity to passing objects by reference, but they're not the same.
Tried replying to 26, got "general error occurred," post did not show up (at least as of when I started this one). This is in reply to OP.
- Edit -
No error when posting that reply, and now I see my other reply showed up. Wow, a burp in the forums. How surprising.
--
Message was edited by:
jverd
You make a good point. Contrary to my expectation the following code outputs 1,1 (not 1,2)
public class Sandbox {
public static void main(String [] args) {
int a = 1 ;
Integer b = 1 ;
intTest(a) ;
intTest(b) ;
System.out.println(a + ", " + b) ;
}
public static void intTest(int i) {
i = 2 ;
}
public static void intTest(Integer i) {
i = new Integer(2) ;
}
}
If Integer objects weren't immutable, I could achieve pass by reference behavior with a hypothetical method like
public static void intTest(Integer i) {
i.setValue(2) ;
}
The key difference is modifying the contents of a reference (the latter hypothetical) vs reassigning the value of a reference (the failed attempt at the beginning).
So the moral is, assuming that all wrapper classes are immutable, there is actually no functional difference is this regard.
> Tried replying to 26, got "general error occurred,"
> post did not show up (at least as of when I started
> this one). This is in reply to OP.
>
>
>
> - Edit -
> No error when posting that reply, and now I see my
> other reply showed up. Wow, a burp in the forums. How
> surprising.
> --
>
> Message was edited by:
> jverd
I think it's the reply to reply bug. All these threads trace back to my original reply to CaptainMorgan who edited at the same time I posted. I got the error in that reply and all replies to that reply.
> You make a good point. Contrary to my expectation the
> following code outputs 1,1 (not 1,2)
If by "good point" you mean what cotton.m posted was entirely accurate whereas what you posted was just plain wrong. There is no debate on this issue, Java does not have pass-by-reference and nothing you can do in Java is the same as pass-by-reference.
> If Integer objects weren't immutable, I could achieve
> pass by reference behavior with a hypothetical method
> like
No you couldn't because that isn't pass-by-reference.
> he key difference is modifying the contents of a
> reference (the latter hypothetical) vs reassigning
> the value of a reference (the failed attempt at the
> beginning).
The key is that you're modifying a field in the object that the reference "points" to as opposed to changing the value of the reference. That is not pass-by-reference, it does not emulate pass-by-reference and it is not the same as pass-by-reference.
> So the moral is, assuming that all wrapper classes
> are immutable, there is actually no functional
> difference is this regard.
I'm not sure what you mean by this.
