-1

I cannot understand the definition. Here's some code:

Integer iW;
for (iW = 1; iW < 4; iW++)
   System.out.println(iW);
int i = iW;
iW += 6;
System.out.println(String.format("iW = %d, i = %d", iW , i));

Outputs this:

1
2
3
iW = 10, i = 4

What is going on, exactly? Integer object iW sure looks like it's changing to me. In other uses, it actually seems to behave a bit more like a local object (not reference variable/pointer type), if I can bend my old C++ mind to this. But, it sure looks mutable.

P.S. Thanks for all the down-votes with no explanation why! I have, actually, read about every post on this topic before asking this question. Integer is an immutable class, and the hugely upvoted responses suggest (to my eye, at least) that this means you cannot mutate, i.e., change, an instance of the class. Yet, the above code sample appears to show that the object iW, or the object it references, does mutate. I still want to know what immutable class means in Java, especially from a coding standpoint, since it does not prevent the apparent mutation of immutable class instances.

closed as off-topic by gnat, Ixrec, Matthew Flynn, enderland, amon Feb 21 '16 at 17:10

This question appears to be off-topic. The users who voted to close gave this specific reason:

  • "Questions asking for assistance in writing or debugging existing code are off-topic on Programmers. These questions can be asked on Stack Overflow if they include the desired behavior, a specific problem or error, and the shortest code necessary to reproduce it in the question itself. See How To Create a Minimal, Complete, and Verifiable Example." – gnat, Ixrec, Matthew Flynn, enderland, amon
If this question can be reworded to fit the rules in the help center, please edit the question.

  • 1
    Welcome to the world of boxing and unboxing where an immutable wrapper class becomes its numeric primitive and then back again, all under the covers. – user40980 Feb 16 '16 at 3:35
  • @gnat Well, I thought I understood boxing/unboxing. But, if what you (and @Basilevs) are saying is that iW in this sequence is actually a reference to an object/instance that is, in fact, being replaced all the time behind the curtain, it makes immutable a pretty slippery term, doesn't it? I mean, what, exactly is immutable - the object to which I no longer hold a reference? Not being able to change what effectively no longer exists is not exactly a feature... – Kloder Feb 16 '16 at 16:28
  • 1
    Immutable doesn't mean constant. String foo = "foo"; foo = "bar"; - String is immutable. foo is a variable. – user40980 Feb 16 '16 at 22:58
  • I suspect the majority of the votes are because you haven't sat down and run this through a debugger (something every developer should know how to do) and looked at the information that it presents. This would show that you are not actually mutating an object but rather working with a multitude of them. – user40980 Feb 17 '16 at 0:50
2

Lets look at some code.

public class Ints {
    public static void main(String[] args) {
        Integer iW;
        for (iW = 1; iW < 4; iW++)
            System.out.println(iW);
        int i = iW;
        iW += 6;
        System.out.println(String.format("iW = %d, i = %d", iW , i));
    }
}

This should be rather familiar. But now, lets look at what it compiles and decompiles to:

public class Ints {
    public Ints() {
    }

    public static void main(String[] args) {
        Integer iW;
        for(iW = Integer.valueOf(1); iW.intValue() < 4; iW = Integer.valueOf(iW.intValue() + 1)) {
            System.out.println(iW);
        }

        int i = iW.intValue();
        iW = Integer.valueOf(iW.intValue() + 6);
        System.out.println(String.format("iW = %d, i = %d", new Object[]{iW, Integer.valueOf(i)}));
    }
}

And there you see it happening - the conversion of the Integer to an int and back again.

The line that you thought was iW += 6 is actually iW = Integer.valueOf(iW.intValue() + 6);

This is a process known as boxing (that's a Java Tutorial from Oracle - rather good read).

Autoboxing is the automatic conversion that the Java compiler makes between the primitive types and their corresponding object wrapper classes. For example, converting an int to an Integer, a double to a Double, and so on. If the conversion goes the other way, this is called unboxing.

This is done by the compiler for you. It makes the code easier to write. And as long as you aren't doing things you shouldn't (like comparing equality between Integers with == which can bite you in the posterior quite hard), its doing what you want it to.

If you fire up a debugger you will see these objects being created or recalled form other sources.

On my machine, when iW is 1, the actual object is Integer@426 under the scenes. When iW is 2, the actual object is Integer@432 and so on. I haven't changed Integer@426 (value=1) when it is incremented - rather a new object is created that has a value one higher.

What immutable actually means is that you cannot do iW.setValue(10). That doesn't work. You cannot change the state of the object that iW points to. With autoboxing, you can quickly and easily change which object you are pointing to, but the underlying object cannot be changed.

String is immutable - even though the abomination feature of String foo = "foo"; foo += "bar"; works (thats actually more involved than the Integer magic as it means allocating a new StringBuilder). Look also at BigInteger, Color or InetAddress. Look for the methods that will allow you to mutate the state of the object that you have. That is what immutable means.

  • Thank you. That explains it. I use a debugger (have for a few decades, but Java/Eclipse/IDEA is new to me). I have not done a decompile, obviously, but your code does show what the other answers were leading me to, i.e., that new objects are created to replace the initial instance. Just an opinion, but the definition of Autoboxing, as a conversion, without mentioning the creation of a new instance every single time could be more transparent. – Kloder Feb 17 '16 at 2:06
-3

iW is not an object, it is a variable holding a reference to different objects. Reference changes, objects are created and referenced, without need to change.

Not the answer you're looking for? Browse other questions tagged or ask your own question.