Variable Assignment

[J Solomon]

public static void main(String[] args) {

        int x = 10;
        int y = x;

        System.out.println("Before...");
        System.out.println("x is: " + x);
        System.out.println("y is: " + y);

        x = 20;

        System.out.println("After re-assigning x");
        System.out.println("x is: " + x);
        System.out.println("y is: " + y);

}

What I would expect to print:

Before...
x is: 10
y is: 10
After re-assigning x
x is: 20
y is: 20

What actually prints:

Before...
x is: 10
y is: 10
After re-assigning x
x is: 20
y is: 10

I'm assuming that when you declare y and assign it to x, you are actually copying the actual value that lives at location aliased by x. Is this a pass by value as opposed to pass by reference?
Can someone please explain this one to me?

Thanks.

[Knute Snortum]

int is a primitive and not an object.

[Junilu Lacar]

J Solomon wrote:[I'm assuming that when you declare y and assign it to x, you are actually copying the actual value that lives at location aliased by x. Is this a pass by value as opposed to pass by reference?
Can someone please explain this one to me?

Your code declares y and assigns the value of x to it; you're not assigning y to x.

Yes, the current value of x is "copied" to y on line 4.

Pass by value vs pass by reference does not come into play here -- this only relates to parameters passed to methods and parameters are ALWAYS passed by value in Java.

Also, whether or not the values are objects doesn't really matter in this particular case. If you were to declare x and y as Integer instead of int, the result would be the same. There is a way you would get the results you're expecting though but that would entirely different code/classes.

[Sunni srivastav]

I can understand that you are trying to correlate Java with C/C++.

Let us try to do it then

Logically if there are two variables let it be "X" and "Y",then for your code there are two cases

Case 1: X and Y are two variables where each point to different memory location with same set of values.
Eg: X = 10 ,Memory location=6999(some random assumption)
Y=10 , Memory location=50000
Now if you make change to X it is reflected only for X and not for Y.

Case 2: If both are pointing to a value in same memory location.
Then if one is changed, the same is reflected for the other.


The primitive assignment operations falls under Case I.Hope this answers your questions.


Carry on with your java exploration the object/class reference concept will become cleared gradually.

[Winston Gutkowski]

Sunni srivastav wrote:I can understand that you are trying to correlate Java with C/C++.

But even then, it's wrong, because y in NOT an alias of x in any of those languages. &x might be, but it rather depends on context.

@Sunni: They are simply two separate value fields; just as they are in C or C++ - and there is no '&' qualifier in Java.

HIH

Winston

[J Solomon]

What about the following example..........

public class Foo {

    private String name;

    public Foo(String name) {
        this.name = name;
    }

    public String getName() {
        return this.name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public static void main(String[] args) {

        Foo e = new Foo("something");
        Foo s = e;

        System.out.println("Before....");
        System.out.println("e.name is: " + e.getName());
        System.out.println("s.name is: " + s.getName());

        e.setName("CHANGED");

        System.out.println("After....");
        System.out.println("e.name is: " + e.getName());
        System.out.println("s.name is: " + s.getName());

    }

What gets printed:

Before....
e.name is: something
s.name is: something
After....
e.name is: CHANGED
s.name is: CHANGED

[Henry Wong]

J Solomon wrote:What about the following example..........

In this second example, you have two reference variables pointing to the same object.

Are you expecting it to behave different than what you got?

Henry

[Knute Snortum]

public class AssignMe {
	public static void main(String[] args) {
		Integer x = new Integer(10);
		Integer y = x;
		x = 20;
		System.out.println("x = " + x + ", y = " + y ); // y = 10
	}
}

Is the reason y is still 10 because of auto-unboxing?

[Junilu Lacar]

Knute Snortum wrote:Is the reason y is still 10 because of auto-unboxing?

I suppose in a way, yes. You get the same results if you change the type to String, with appropriate adjustments to the values used, of course. In fact, it can be any object type as long as line 05 is assigning a new instance to x. The crux of it is that you're assigning a new value to the variable rather than changing the state of the current value being referenced (see the OP's other example that uses objects and a setter to change the state). In the case of autoboxing of an int, the Integer that results from autoboxing is always a new instance. That is,

Line 3, x references a new Integer(10) instance
Line 4, y references same Integer(10) that x references
Line 5, x references a new Integer(20); y still references the Integer(10) created on Line 3

[Knute Snortum]

So if the Integer class had a setInt() method and line five was

x.setInt(20);

then y would be 20 also. As it is, line five is in effect

x = new Integer(20);

[Junilu Lacar]

I wrote:In the case of autoboxing of an int, the Integer that results from autoboxing is always a new instance.

I take (some of) that back. Technically, autoboxed int values from -127-128 to 127 will always be the same pre-existing(?) Integer instances (I guess they're intern'ed by the JVM or something like that). Any int values outside this range will result in new instances when autoboxing is done.

Integer a = 10;
Integer b = 10;
System.out.println(a == b); // true
// same results if values from -128 to 127 used above

a = 128;
b = 128;
System.out.println(a == b); // false

I know, it's kind of weird. Don't ever abuse code with this knowledge though. (Edit: the correct range is -128 to 127 where a == b will be true)

[Darryl Burke]

Junilu Lacar wrote:Technically, autoboxed int values from -127-128 to 127 will always be the same pre-existing(?) Integer instances (I guess they're intern'ed by the JVM or something like that).

No, they are cached in the private nested class Integer.IntegerCache. See Integer.java around lines 580 - 606 (Java SE 6).

Don't ever abuse code with this knowledge though.

It wouldn't be abuse. This behavior is defined in the JLS: http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7-300

[Junilu Lacar]

Darryl Burke wrote:

Junilu Lacar wrote:Technically, autoboxed int values from -127-128 to 127 will always be the same pre-existing(?) Integer instances (I guess they're intern'ed by the JVM or something like that).

No, they are cached in the private nested class Integer.IntegerCache. See Integer.java around lines 580 - 606 (Java SE 6).

Thanks for the clarification.

It wouldn't be abuse. This behavior is defined in the JLS: http://docs.oracle.com/javase/specs/jls/se8/html/jls-5.html#jls-5.1.7-300

The behavior is not widely known and if you didn't know it, you wouldn't expect it. I don't really care if the JLS defines the behavior; if someone writes code like that below, I would take them out behind the woodshed.

boolean isEqual(Integer x, Integer y) {
   // since x and y will only ever be within -128 and 127
   return x == y;  
}
// Code review notes:
// 1. Noooooo! Use equals()! 
// 2. Comments are NOT to be used as stand-ins for assertions!!!

[Campbell Ritchie]

Junilu Lacar wrote: . . . Technically, autoboxed int values from -127-128 to 127 will always be the same pre-existing(?) Integer instances . . .

It is possible to increase that range. The JVM says it would be better to cache every boxed Integer:

The same link that Darryl quoted wrote:Ideally, boxing a primitive value would always yield an identical reference. In practice, this may not be feasible using existing implementation techniques.

[Junilu Lacar]

Campbell Ritchie wrote:The JVM says it would be better to cache every boxed Integer

You meant "The JLS...", right?

Yeah, I noticed that and the other stuff, too. I believe these are in the specs to help JVM implementers rather than provide some kind of "trick" for programmers. Note that the text that you referred to is in fine print and I doubt that was arbitrary.

Programmers should never use "==" to check for value equality of objects, even if in the case of the values specified by the JLS, equals and == are essentially equivalent. The first problem is that the range of values depends on the implementation, so the logic may not result in the same behavior from one implementation to another. Second and more importantly, this is an obscure part of the specification and anyone who doesn't know it will immediately think there's a problem when they see code that uses == where equals() is actually the intent. That to me would count as abuse.

[Campbell Ritchie]

Yes, you are right. My spelling of JLS has been getting worse recently.

It did say “ideally”. They obviously felt constrained by the availability of memory when that Java5 JLS was written. The Java8 JLS section looks exactly the same, however.