• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Variable Assignment

 
Ranch Hand
Posts: 30
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Sheriff
Posts: 7125
184
Eclipse IDE Postgres Database VI Editor Chrome Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
int is a primitive and not an object.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Greenhorn
Posts: 24
Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.


 
Bartender
Posts: 10780
71
Hibernate Eclipse IDE Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
    Number of slices to send:
    Optional 'thank-you' note:
  • 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


 
author
Posts: 23951
142
jQuery Eclipse IDE Firefox Browser VI Editor C++ Chrome Java Linux Windows
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 7125
184
Eclipse IDE Postgres Database VI Editor Chrome Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator


Is the reason y is still 10 because of auto-unboxing?
 
Junilu Lacar
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 7125
184
Eclipse IDE Postgres Database VI Editor Chrome Java Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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)
 
Bartender
Posts: 5167
11
Netbeans IDE Opera Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.

 
Marshal
Posts: 79180
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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: 79180
377
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
reply
    Bookmark Topic Watch Topic
  • New Topic