• Post Reply Bookmark Topic Watch Topic
  • New Topic

Variable Assignment  RSS feed

 
J Solomon
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator



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
Sheriff
Posts: 4287
127
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
int is a primitive and not an object.
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Greenhorn
Posts: 24
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Bartender
Posts: 10575
66
Eclipse IDE Hibernate Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
What about the following example..........




What gets printed:

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


 
Henry Wong
author
Sheriff
Posts: 23295
125
C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 4287
127
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator


Is the reason y is still 10 because of auto-unboxing?
 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 4287
127
Chrome Eclipse IDE Java Postgres Database VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
So if the Integer class had a setInt() method and line five was



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

 
Junilu Lacar
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


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
Bartender
Posts: 5167
11
Java Netbeans IDE Opera
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Campbell Ritchie
Marshal
Posts: 56585
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Sheriff
Posts: 11494
180
Android Debian Eclipse IDE IntelliJ IDE Java Linux Mac Spring Ubuntu
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Marshal
Posts: 56585
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!